Mens Git-brugere har snesevis af startvejledninger at vælge imellem, og GitHub tilbyder en række egne guider, er det stadig ikke let at finde en samling nyttige tip til udviklere, der ønsker at arbejde smartere med Git og GitHub. Lad os ordne det.
For de af jer, der ikke er bekendt med Git eller GitHub, vil de næste par afsnit give dig nok baggrund til at forstå tipene. Vi viser en række nyttige ressourcer i slutningen af denne artikel.
Git er et distribueret versionskontrolsystem, oprindeligt skrevet af Linus Torvalds i 2005 til og med hjælp fra Linux-kernesamfundet. Jeg er ikke her for at sælge dig på Git, så jeg sparer dig for spillet, hvor hurtigt og lille og fleksibelt og populært det er, men du skal vide, at når du kloner et Git-arkiv ("repo", kort) , får du hele versionshistorikken på din egen computer, ikke kun et øjebliksbillede fra en gren ad gangen.
Git startede som et kommandolinjeværktøj, der passer til dets oprindelse i Linux-kernesamfundet. Du kan stadig bruge Git-kommandolinjen, hvis du vil, men du behøver ikke. Især hvis du bruger GitHub som din vært, kan du bruge den gratis GitHub Desktop-klient på Windows eller Mac. På den anden side fungerer Git-kommandolinjen for enhver vært, og den kommer forudinstalleret på de fleste Mac- og Linux-systemer.
Kun du kan beslutte, om du er mest fortrolig med at bruge kommandolinjen eller en indfødt klient med en grafisk brugergrænseflade. Hvis du kan lide en GUI ud over GitHub-klienten (Windows og Mac), kan du måske overveje SourceTree (Windows og Mac, gratis), TortoiseGit (kun Windows, gratis) og Gitbox (kun Mac, $ 14,99). Eller du kan bruge en editor eller IDE, der understøtter Git internt (se tip nr. 11).
Git / GitHub tip nr. 1: Klon næsten hvad som helst
Der er mange interessante projekter tilgængelige fra GitHub og andre offentlige Git-arkiver, som du frit kan klone til din egen computer. Hvorfor vil du gøre det? En af grundene er at lære noget om kodningstilstand, praksis og værktøjer på et sprog af interesse, herunder begå logkommentar-stil (se tip nr. 4). En anden grund er at lære, hvordan et givet projekt opfylder sine mål. En tredje grund, hvis licensen både tillader dig at gøre det og giver mening til dine formål, ville være at inkorporere projektet i din egen indsats eller dit produkt. Dobbelttjek licensen forresten, så du ikke løber ind i overholdelsesproblemer senere.
Definitionen af git klon fra manualsiden:
Kloner et lager i en nyoprettet mappe, opretter fjernsporingsgrene for hver gren i det klonede lager (synlig ved hjælp af git gren -r), og opretter og tjekker en indledende gren, der sendes fra det klonede arkivs aktuelt aktive gren.
Efter klonen, en slette git-hentning uden argumenter opdaterer alle fjernsporingsgrene, og a git pull uden argumenter vil derudover fusionere den eksterne masterfilial i den aktuelle masterfilial, hvis nogen.
Git / GitHub tip nr. 2: Træk ofte
En af de nemmeste måder at lave et rod for dig selv med Git (og faktisk med ethvert versionskontrolsystem) er at lade filer komme ud af synkronisering. hvis du git pull ofte holder du din kopi af repoen opdateret, og du får mulighed for at flette din ændrede kode med andres ændringer, mens fletningen er let at forstå og udføre - ideelt når det er så let, at det kan gøres automatisk. En følge af dette tip er at se din projektstatus. Mange Git-klienter viser dig automatisk, hvornår du har brug for at opdatere for at holde dig opdateret.
Git / GitHub tip nr. 3: Forpligt tidligt og ofte
En forpligtelse er en detaljeret opdatering til et projekt, der inkluderer en eller flere ændringer til en eller flere filer. Tænk på det som en registrering af en færdigbehandlet enhed, der kan anvendes på eller fjernes fra projektet som en logisk helhed. Foretag enhver logisk ændring, du gennemfører, selv før du tester den. Forpligtelser gælder kun for dit lokale arkiv. Se tip nr. 4 og 5 for følger af dette tip.
Definitionen af git begå fra manualsiden:
Gemmer det aktuelle indhold i indekset i en ny forpligtelse sammen med en logbesked fra brugeren, der beskriver ændringerne.
Git / GitHub-tip nr. 4: Kommenter dine forpligtelser, som du vil have andre til at kommentere deres
Der er 10 slags kodere: Dem, der kommenterer deres forpligtelser, og dem der ikke gør det. (Gammel vittighed. Tip: Hvilken base bruger jeg?)
Jeg indrømmer frit at være klæber til gode log-beskeder. Jeg oprettede mine opbevaringssteder til at kræve beskeder for hver forpligtelse, og jeg har været kendt for at sende irriterede sent om aftenmeddelelser, når jeg forpligter land med logfiler i størrelsesordenen "xx." Hvis du er den slags udvikler, der synes (1) koden skal tale for sig selv, og (2) kommentarerne på linjen er langt vigtigere end ændringsloggene, så prøv at klone et lager, du aldrig har set før, og identificer nylig begivenhed, der muligvis har forårsaget det seneste problem, der er sendt uden at have læst hele koden. Som du kan se, er nøjagtige forpligtelseslogfiler dobbelt plus gode.
Git / GitHub tip nr. 5: Skub, når dine ændringer testes
Den værste Git-relaterede fejl, jeg nogensinde har haft den ulykke at vide om, skete, da et outsourcingfirma skiftede fra Subversion, men ikke trænede sine udviklere om forskellen mellem distribueret kildekontrol og centraliseret kildekontrol. Omkring en måned senere udviklede projektet underlige bugs, som ingen kunne synes at spore. På de daglige stand-up-møder protesterede udviklerne, der var ansvarlige for det område af applikationen, der ikke opførte sig, "Jeg fik ordnet det for to uger siden!" eller beskyld en anden udvikler for ikke at gider at trække de ændringer, de så nøje havde tjekket ind.
Til sidst identificerede nogen problemet og lærte alle udviklerne, hvordan og hvornår de skulle skubbe deres forpligtelser: Kort sagt, når forpligtelserne testes med succes i en lokal build. Derefter foretog virksomheden en to-dages lang fusionsfest, inden den kunne bygge og implementere det opdaterede, integrerede produkt.
Git / GitHub tip nr. 6: Forgren frit
En af de største fordele, Git har i forhold til andre versionskontrolsystemer, er, at fletning normalt fungerer godt, i det mindste delvis fordi Git automatisk vælger den bedste fælles forfader, der skal bruges til en fusion. De fleste softwareudviklere skal oftere begynde at oprette filialer i deres projekter. Det burde være en rutinemæssig daglig forekomst, ikke genstand for et kvalificeret strategimøde for alle hænder. Sandsynligheden er, at når filialprojektet er afsluttet, accepteret og klar til at gå ind i hovedprojektet, vil fusionen ikke give uoverstigelige problemer.
Jeg ved, det kræver en vis tilpasning, især hvis du har været fast i et firma, der styrer kildekoden med CVS. Men prøv det. Det er meget bedre end at kunder ved et uheld ser din ufærdige eksperimentelle kode, når bagagerumsprojektet skal offentliggøres på grund af en brudende fejl. (Denne artikel forklarer grundlæggende forgrening og fletning godt.)
Git / GitHub tip nr. 7: Flet forsigtigt sammen
Mens fusioner med Git normalt fungerer godt, kan du lejlighedsvis støde på problemer, hvis du gør dem uden at tænke over det. Trin et er at sikre, at du ikke har nogen uforpligtende ændringer. Fra git fusion manuel side:
Inden du anvender ændringer udefra, skal du få dit eget arbejde i god form og engageret lokalt, så det bliver ikke klodset, hvis der er konflikter. Se også git-stash.
Se også tip nr. 8.
Selvom det hele går sydpå i løbet af en git fusion, du får ikke slange:
Hvis du prøvede en fletning, der resulterede i komplekse konflikter og vil starte forfra, kan du komme dig igen med git merge —abort.
Opfølgningskommandoen til git fusion er normalt git mergetoolforudsat at du kan lide at bruge en GUI til fletning. Hvis du foretrækker den gamle skolemetode, kan du redigere filerne i konflikt med din foretrukne programmeringseditor, fjerne filerne fuldt ud <<<<<<<, =======og >>>>>>> linjer, gem de reviderede filer og git add hver fil, du har rettet.
Git / GitHub tip nr. 8: Stash før skift af gren
En softwareudviklers arbejdsgang er sjældent lineær. Brugere har tøven til at rapportere bugs, ledere har frækhed til at prioritere andre billetter end den, du valgte at arbejde på, og du kan selv ændre mening om, hvad du vil gøre.
Der er du med tre filer forpligtet til frigivelse og en fjerde fil i en ændret, men ikke-fungerende tilstand. (Det git status kommandoen fortæller dig alt dette, hvis du ikke tilfældigvis husker, hvor du var.) Pludselig skal du arbejde på en fejlrettelse i en produktionsversion. Du skal skifte filial pronto, men du kan ikke. Din arbejdsmappe er beskidt, og du har to timers arbejde, du ikke vil miste.
Gå ind git stash. Voilà! Nu har du gemt alle dine ændringer i en WIP-gren (igangværende arbejde), og du kan skifte til produktionsgrenen fra din rene bibliotek. Når du er færdig med det, skal du skifte tilbage til det sted, hvor du var git stash gælder.
Git / GitHub-tip nr. 9: Brug gists til at dele uddrag og pastaer
GitHub “gists” - delte kodestykker - er ikke en Git-funktion, men de bruger Git. Alle gists er Git-arkiver, og GitHub Gist gør det let at dele dem. Du kan søge i Gist efter offentlige gister efter emne, programmeringssprog, forked status og stjernestatus. Du kan også oprette hemmelige gister og dele dem efter URL.
Git / GitHub tip nr. 10: Udforsk GitHub
Mange interessante open source-projekter har opbevaringssteder på GitHub. Udforsk GitHub giver en browsergrænseflade for at finde nogle af dem, men for det meste er det lettere at skrive et par bogstaver i projektets navn i søgefeltet for at finde dets repos. Skriv f.eks jq eller tilbage eller ang for at finde tre af de store open source JavaScript-rammer.
Git / GitHub tip nr. 11: Bidrag til open source-projekter
Så længe du gennemsøger open source-projekter, hvorfor ikke bidrage til dem? Det er ikke så svært, som du måske tror, og du lærer meget. For eksempel kan du klone projektet jquery / jquery (jQuery Core) og gennemse README.MD. Nær toppen ser du:
I ånden med open source softwareudvikling tilskynder jQuery altid community code-bidrag. For at hjælpe dig i gang, og inden du hopper ind i at skrive kode, skal du læse disse vigtige retningslinjer for bidrag grundigt ...
Det er efterfulgt af tre links. Den første af de tre får dig i gang ret hurtigt. Ikke alle open source-projekter opstiller planen så tydeligt, men de prøver alle.
Forstå forskellen mellem at være en bidragyder og en kommitter. En bidragyder har underskrevet de krævede aftaler og stillet et bidrag til rådighed for projektet. En kommissær har beføjelse til faktisk at forpligte det tilbudte bidrag til projektlageret. Fordi der vil være en forsinkelse, mens en kommissionær tester dit bidrag, og du ikke ønsker at binde din mastergren, skal du foretage dine ændringer i en anden gren (se tip nr. 6), inden du sender en pull-anmodning (se tip nr. 16).
