Mens Git-brukere har dusinvis av startveiledninger å velge mellom, og GitHub tilbyr en rekke egne guider, er det fortsatt ikke lett å finne en samling nyttige tips for utviklere som ønsker å jobbe smartere med Git og GitHub. La oss fikse det.
For de av dere som ikke er kjent med Git eller GitHub, vil de neste par avsnittene gi deg nok bakgrunn til å forstå tipsene. Vi vil liste opp et titalls nyttige ressurser på slutten av denne artikkelen.
Git er et distribuert versjonskontrollsystem, opprinnelig skrevet av Linus Torvalds i 2005 for og med hjelp fra Linux-kjernesamfunnet. Jeg er ikke her for å selge deg på Git, så jeg vil spare deg for spielet om hvor raskt og lite og fleksibelt og populært det er, men du bør vite at når du kloner et Git-depot ("repo", kort) , får du hele versjonshistorikken på din egen datamaskin, ikke bare et øyeblikksbilde fra en gren om gangen.
Git startet som et kommandolinjeverktøy som passer til opprinnelsen i Linux-kjernefellesskapet. Du kan fortsatt bruke Git-kommandolinjen, hvis du vil, men du trenger ikke. Spesielt hvis du bruker GitHub som vert, kan du bruke den gratis GitHub Desktop-klienten på Windows eller Mac. På den annen side vil Git-kommandolinjen fungere for alle verter, og den kommer forhåndsinstallert på de fleste Mac- og Linux-systemer.
Bare du kan bestemme om du er mest komfortabel med å bruke kommandolinjen eller en innfødt klient med et grafisk brukergrensesnitt. Hvis du liker en GUI, i tillegg til GitHub-klienten (Windows og Mac), vil du kanskje vurdere SourceTree (Windows og Mac, gratis), TortoiseGit (bare Windows, gratis) og Gitbox (kun Mac, $ 14,99). Eller du kan bruke en editor eller IDE som støtter Git internt (se tips nr. 11).
Git / GitHub-tips nr. 1: Klon nesten hva som helst
Det er mange interessante prosjekter tilgjengelig fra GitHub og andre offentlige Git-arkiver som du kan klone fritt til din egen datamaskin. Hvorfor vil du gjøre det? Én grunn er å lære noe om kodestil, praksis og verktøy på et språk av interesse, inkludert kommittestil for loggkommentarer (se tips nr. 4). En annen grunn er å lære hvordan et gitt prosjekt oppnår målene. En tredje grunn, hvis lisensieringen både tillater deg å gjøre det og gir mening for dine formål, er å innlemme prosjektet i din egen innsats eller ditt produkt. Dobbeltsjekk for øvrig lisensen, slik at du ikke får problemer med overholdelse senere.
Definisjonen av git klon fra manualsiden:
Kloner et depot i en nyopprettet katalog, oppretter fjernsporingsgrener for hver gren i det klonede depotet (synlig ved hjelp av git gren -r), og oppretter og sjekker ut en innledende gren som gaffles fra det klonede depotets aktive gren.
Etter klonen, en slette git-henting uten argumenter vil alle oppdateringssporingsgrenene oppdateres, og a git pull uten argumenter vil i tillegg slå sammen den eksterne hovedgrenen i den aktuelle hovedgrenen, hvis noen.
Git / GitHub-tips nr. 2: Trekk ofte
En av de enkleste måtene å lage et rot for deg selv med Git (og faktisk med hvilket som helst versjonskontrollsystem) er å la filer komme ut av synkronisering. Hvis du git pull ofte vil du holde kopien av repoen oppdatert, og du vil få muligheten til å slå sammen den endrede koden med andres endringer mens sammenslåingen er lett å forstå og oppnå - ideelt når det er så enkelt at det kan gjøres automatisk. En følge av dette tipset er å se prosjektstatusen din. Mange Git-klienter viser deg automatisk når du trenger å oppdatere for å holde deg oppdatert.
Git / GitHub-tips nr. 3: Forplikt deg tidlig og ofte
En forpliktelse er en detaljert oppdatering av et prosjekt, som inkluderer en eller flere endringer i en eller flere filer. Tenk på det som en oversikt over en fullført arbeidsenhet, som kan brukes på eller fjernes fra prosjektet som en logisk helhet. Gjør hver logiske endring du fullfører, selv før du tester den. Forpliktelser gjelder bare for ditt lokale depot. Se tips nr. 4 og 5 for resultatene til dette tipset.
Definisjonen av git begå fra manualsiden:
Lagrer det nåværende innholdet i indeksen i en ny kommisjon sammen med en loggmelding fra brukeren som beskriver endringene.
Git / GitHub-tips nr. 4: Kommenter forpliktelsene dine slik du vil at andre vil kommentere deres
Det er ti typer kodere: De som kommenterer sine forpliktelser, og de som ikke gjør det. (Gammel vits. Tips: Hvilken base bruker jeg?)
Jeg innrømmer fritt å være klistremerke for gode loggmeldinger. Jeg satte opp lagringsplassene mine for å kreve meldinger for hver forpliktelse, og jeg har vært kjent for å sende ut irriterte sent på kvelden når jeg forplikter land med logger i størrelsesorden “xx.” Hvis du er den typen utvikler som mener (1) koden skal snakke for seg selv, og (2) kommentarene på linjen er viktigere enn endringsloggene, kan du prøve å klone et depot du aldri har sett før og identifisere nylig forpliktelse som kan ha forårsaket den siste utgaven som ble lagt ut uten å lese hele koden. Som du kan se, er nøyaktige forpliktelseslogger dobbelt pluss gode.
Git / GitHub-tips nr. 5: Trykk når endringene dine blir testet
Den verste Git-relaterte feilen jeg noensinne har hatt den ulykken å vite om, skjedde da et outsourcingfirma byttet fra Subversion, men ikke trente utviklerne om forskjellen mellom distribuert kildekontroll og sentralisert kildekontroll. Omtrent en måned senere utviklet prosjektet rare bugs som ingen kunne se ut til å spore. På de daglige stand-up-møtene protesterte utviklerne som var ansvarlige for applikasjonsområdet som ikke oppførte seg, "Jeg fikset det for to uker siden!" eller beskyld en annen utvikler for ikke å gidde å trekke endringene de hadde så nøye sjekket inn.
Til slutt identifiserte noen problemet og lærte alle utviklerne hvordan og når de skulle gjøre det trykk deres forpliktelser: Kort sagt, når forpliktelsene tester vellykket i en lokal bygning. Så gjorde selskapet en to dager lang sammenslåingsfest før de kunne bygge og distribuere det oppdaterte, integrerte produktet.
Git / GitHub-tips nr. 6: Forgren deg fritt
En av de største fordelene Git har over noen andre versjonskontrollsystemer er at sammenslåing vanligvis fungerer bra, i det minste delvis fordi Git automatisk velger den beste felles forfedren som skal brukes til en sammenslåing. De fleste programvareutviklere må oftere begynne å lage filialer i sine prosjekter. Det skal være en rutinemessig daglig forekomst, ikke gjenstand for et kvalmefullt all-hands strategimøte. Sannsynligheten er at når avdelingens prosjekt er fullført, akseptert og klar til å gå inn i hovedprosjektet, vil sammenslåingen ikke by på uoverstigelige problemer.
Jeg vet at det krever litt justering, spesielt hvis du har sittet fast i et selskap som kontrollerer kildekoden med CVS. Men prøv det. Det er mye bedre enn at kunder ved et uhell ser den uferdige eksperimentelle koden din når koffertprosjektet må publiseres på grunn av en ødeleggende feil. (Denne artikkelen forklarer grunnleggende forgrening og sammenslåing godt.)
Git / GitHub tips nr. 7: Slå forsiktig sammen
Mens sammenslåinger med Git vanligvis fungerer bra, kan du av og til støte på problemer hvis du gjør dem uten å tenke. Trinn 1 er å sørge for at du ikke har noen uforpliktende endringer. Fra git flette manuell side:
Før du bruker eksterne endringer, bør du få ditt eget arbeid i god form og engasjert lokalt, slik at det ikke blir sperret hvis det er konflikter. Se også git-stash.
Se også tips nr. 8.
Selv om det hele går sørover i løpet av en git flette, du får ikke slange:
Hvis du prøvde en sammenslåing som resulterte i komplekse konflikter og vil starte på nytt, kan du komme deg med git merge —abort.
Oppfølgingskommandoen til git flette er vanligvis git mergetoolforutsatt at du liker å bruke et GUI for sammenslåing. Hvis du foretrekker den gamle skolemetoden, kan du redigere filene i konflikt med favorittprogrammeringseditoren din, fjerne filene <<<<<<<, =======, og >>>>>>> linjer, lagre de reviderte filene og git add hver fil du fikset.
Git / GitHub-tips nr. 8: Stash før du bytter gren
En arbeidsutvikling for en programvareutvikler er sjelden lineær. Brukere har tøven til å rapportere feil, ledere har frimodighet til å prioritere andre billetter enn den du valgte å jobbe med, og du kan selv ombestemme deg om hva du vil gjøre.
Der er du, med tre filer forpliktet til utgivelse, og en fjerde fil i en endret, men ikke-fungerende tilstand. (De git status kommandoen vil fortelle deg alt dette hvis du ikke tilfeldigvis husker hvor du var.) Plutselig må du jobbe med en feilretting i en produksjonsversjon. Du må bytte avdeling pronto, men du kan ikke. Arbeidskatalogen din er skitten, og du har to timers arbeid du ikke vil miste.
Tast inn git stash. Voilà! Nå har du alle endringene lagret i en WIP-gren (arbeid pågår), og du kan bytte til produksjonsgrenen fra din rene katalog. Når du er ferdig med det, bytter du tilbake til hvor du var med git stash gjelder.
Git / GitHub-tips nr. 9: Bruk gists til å dele utdrag og pastaer
GitHub “gists” - delte kodebiter - er ikke en Git-funksjon, men de bruker Git. Alle gistene er Git-arkiver, og GitHub Gist gjør det enkelt å dele dem. Du kan søke i Gist etter offentlige gister etter emne, programmeringsspråk, forked status og stjernestatus. Du kan også opprette hemmelige gists og dele dem etter URL.
Git / GitHub-tips nr. 10: Utforsk GitHub
Mange interessante open source-prosjekter har arkiver på GitHub. Utforsk GitHub tilbyr et surfegrensesnitt for å finne noen av dem, men det er for det meste lettere å skrive noen få bokstaver av prosjektets navn i søkeboksen for å finne repoer. Skriv for eksempel jq eller tilbake eller ang for å finne tre av de store open source JavaScript-rammene.
Git / GitHub-tips nr. 11: Bidra til open source-prosjekter
Så lenge du surfer på open source-prosjekter, hvorfor ikke bidra til dem? Det er ikke så vanskelig som du kanskje tror, og du vil lære mye. For eksempel kan du klone prosjektet jquery / jquery (jQuery Core) og bla gjennom README.MD. Nær toppen ser du:
I ånden av programvareutvikling med åpen kildekode, oppfordrer jQuery alltid samfunnskodebidrag. For å hjelpe deg i gang og før du hopper til å skrive kode, må du lese disse viktige retningslinjene for bidrag grundig ...
Det er fulgt av tre lenker. Den første av de tre kommer i gang ganske raskt. Ikke alle open source-prosjekter legger planen så tydelig ut, men de prøver alle.
Forstå forskjellen mellom å være en bidragsyter og en committer. En bidragsyter har signert de nødvendige avtalene og gjort et bidrag tilgjengelig for prosjektet. En kommittør er bemyndiget til å faktisk begå det tilbudte bidraget til prosjektregisteret. Fordi det vil være en forsinkelse mens en kommisjonær tester ditt bidrag, og du ikke ønsker å knytte hovedgrenen din, bør du gjøre endringene i en annen gren (se tips nr. 6) før du sender ut en trekkforespørsel (se tips Nei .16).
