Slik bruker du Git-grener til å strukturere ditt programmeringsprosjekt

Film og TV viser programmering som en hektisk aktivitet Hollywood Hacks: Den beste og verste Hacking i filmer Hollywood Hacks: Den beste og verste Hacking i filmer Hollywood og hacking kommer ikke sammen. Mens ekte hacking er vanskelig, involverer filmhacking ofte bare å skje på et tastatur som at fingrene dine går ut av stil. Les mer . En bombe er tidtakeren teller ned, og den nerdy sidekick som var en byrde fram til det punktet fungerer feberishly på en bærbar datamaskin. Koden flyr over skjermen til hun treffer den endelige returnøkkelen med en tilfredsstillende klakk! Timeren stopper, og alt er rett i verden igjen. Men programmering er ingenting slik. Det inkluderer designdokumenter, UI-mock-ups og kodeanmeldelser. Og mer enn noe det innebærer prøve-og-feil, spesielt hvis du er en nybegynner (som meg).

Nå er du kanskje allerede overbevist om verdien av å holde kodingsprosjektene dine i kildekontroll Hva er Git og hvorfor du bør bruke Versjonskontroll Hvis du er utvikler Hva er Git og hvorfor du bør bruke Versjonskontroll Hvis du er utvikler Som webutviklere har vi mye tid på å jobbe på lokale utviklingssteder, og laster så opp alt når vi er ferdige. Dette er greit når det bare er deg og endringene er små, ... Les mer. Å begå all denne prøven og feilen til lageret ditt vil gjøre for et stort og ryddig prosjekt, med mange revisjoner. De fleste av de forpliktelsene du gjør, vil inneholde ting som er ødelagte, så hvorfor lagre det? Git gren funksjonen kan bidra til å holde all denne rotete koden vekk fra ting du kjenner, fungerer.

I denne artikkelen ser vi på hva forgrening koden din betyr, hvordan du gjør det, og måter å administrere oppdateringer til “hoved-” gren.

Opprette en Git Branch

Vi har lært fra introduksjonen til kildekontroll Administrer din filversjonering som en programmør med Git Administrer filversjonering som en programmerer med Git-programmerere opprettet versjonskontrollsystemer (VCS) for å løse filversjonskontrollproblemer. La oss se på grunnleggende versjonskontroll ved hjelp av toppsystemet i dag, Git. Les mer at du kan opprette et nytt lager med følgende kommando i en terminal:

git init

Når du gjør dette, oppretter det en skjult katalog i din nåværende sti, kalt “.git.” Hvis du ikke kan se det, kan du se noen av våre tidligere artikler om visning av skjult Den enkle måten å vise skjulte filer og mapper i Windows 10, 8.1 og 7 Den enkle måten å vise skjulte filer og mapper i Windows 10, 8.1 og 7 Trenger du å se skjulte filer og mapper i Windows? Slik viser du dem i Windows 10, 8.1 og 7 slik at ingenting er skjult for deg. Les flere filer Skjul og finn hvilken som helst fil på Mac OS X Skjul og finn hvilken som helst fil på Mac OS X Det er ingen enkel måte å raskt skjule eller avsløre skjulte filer på Mac OS X som det finnes på Windows - men det er mulig. Les mer . Denne katalogen inneholder all nødvendig informasjon for å beholde revisjonshistorikken til filene dine. Når du har satt filbehandleren til å vise skjulte filer, kan du åpne .git-mappen og se en rekke underkataloger. En av disse kalles “refs” (vist i bildet under), og dets “hoder” Underkatalog inneholder oppføringer for alle grener i prosjektet. I begynnelsen har du bare en, kalt “herre.”

Refs-katalogen holder en oversikt over grenen, men ikke selve grenen. I hvert fall ikke grenen du er bruker nå. Disse filene holdes i arbeidskatalogen (“~ / Temp / post-programmering-git-gren” i eksempelet ovenfor) slik at du kan få tilgang til dem på en vanlig måte. Gjør akkurat det, vi lager vår første fil (oppkalt “første-file.txt”) i arbeidskatalogen, dvs.. utenfor .git-katalogen. Kontroller dette ved å bruke trofaste kommandoer fra tidligere intro til git-artikkelen Administrer din filversjonering som en programmerer med Git Behandle din filversjonering som en programmerer med Git-programmerere opprettet versjonskontrollsystemer (VCS) for å løse filversjonskontrollproblemer. La oss se på grunnleggende versjonskontroll ved hjelp av toppsystemet i dag, Git. Les mer :

Vi kan se nå arbeidskatalogen har to filer, den vi har forpliktet, og en skapt automatisk av git (den inneholder meldingen vi nettopp har skrevet).

Nå, la oss lage en ny git-gren kalt “testing”:

git grenen testing

Sjekker ut avdelingen og arbeider i den

Vi kan utstede kommandoen ovenfor uten navn for å få en liste over alle grener, så vel som hvilken vi bruker for øyeblikket (dvs. hvilken er “sjekket ut”):

Nå, hvis vi undersøker katalogstrukturen, ser vi “.git / Refs / hoder” Nå har to filer, en hver for “herre” og “testing.”

Hver av disse er en liste over forpliktelsene som omfatter grenen. For eksempel, hvis vi undersøker “herre” gren med “git logg” kommando, kan vi se en linje for hvert av de begjærene som er gjort til den grenen.

Prosessen av “sjekke ut” en filial betyr at endringer du lager til filer vil være en del av den grenen, men ikke andre grener. For eksempel, anta at vi sjekker ut testgit-grenen med følgende kommando:

git checkout testing

Da legger vi til en linje med tekst til første fil.txt, selvfølgelig forplikter den etterpå. Hvis du bytter tilbake til hovedgrenen, finner du at filen fortsatt er tom (den katt kommandoen viser innholdet på en fil i terminalen):

Men tilbake til “testing” gren, filen har fortsatt den ekstra teksten:

Men alt vi noensinne ser i katalogen riktig er enkeltfilen “første-file.txt.” Hvor er da disse to alternative versjoner av samme fil? .Git-katalogen står for disse endringene, men ikke slik du kan forvente.

Hvordan Git lagrer ting

Hvis du skulle undersøke et depot for andre versjonskontrollsystemer som Subversion, vil du finne at de opprettholder en kopi per revisjon for hver enkelt fil. Dette betyr at hvis du har et arkiv på en fil, så opprett to grener, inneholder repo to forskjellige kopier av den filen. Faktisk bruker du faktisk “svn kopi” som kommandoen for å lage en filial i Subversion! På den annen side opererer git på konseptet av “Endringer.”

Utgangen av ovenstående forteller oss hele innholdet i “stamme” (SVNs versjon av “herre”) har blitt kopiert. Et blikk i en filbehandling bekrefter dette:

De “.Git / objekter” katalogen er hva som inneholder alle disse små endringene, og hver enkelt er sporet med en ID. For eksempel, i underbildet, vil du se filer med lange ID-stilnavn. Hver liv i en mappe oppkalt med to heksadesimale tegn (8c og 8d under).

Sammen utgjør disse mappene og filnavnene IDen for en bestemt endring (faktisk en SHA1-hash). Du kan utforske innholdet deres ved hjelp av git cat-fil kommando. Basert på deres modifiserte datoer, kan vi se den ene begynnelsen “8d” kom først, og det viser ingenting. Mens den starter “8c” inneholder teksten vi legger til filen i “testing” gren.

Takeaway er at git grener (inkludert standard “herre”) er ikke separate “mapper” inneholder kopier av filer. Snarere er de lister over endringer i filer over tid. Dette er mer effektivt lagringsmessig, men resultatet er det samme. Alt du gjør (pause?) I en git-grenen blir der inntil du smelter sammen.

Strategier for sammenslåing Tilbake til hovedavdelingen (For å slette eller ikke slette?)

Anta at du hadde et eksisterende prosjekt med en rekke filer, som du deretter forgrenet seg til “testing,” og jobbet på det. Nå vil du få de endringene tilbake i “herre” gren. Du kan gjøre med følgende fra “herre” gren:

git-fusjonstesting

Forutsatt at det ikke er konflikter, endring bestående av den nye teksten vil være anvendt til “herre.” Resultatet er “første-file.txt” vil være identisk i begge grenene. Likevel var det aldri noe alternativ versjoner av filen.

Nå kommer spørsmålet, hva skal jeg gjøre med avdelingen? Det er to felles strategier for å håndtere grener.

1. En er å holde en git gren som “testing” å leke rundt i (vist ovenfor). Du prøver noen ting ut, og hvis du kan få dem til å fungere sammen, endres endringene tilbake i “herre.” Da kan du avslutte arbeidet på den grenen, eller til og med bli kvitt den helt. Dette betyr din “herre” er den mest stabile versjonen av koden, fordi den bare skal inneholde ting du kjenner arbeid. Du kan også tenke på denne tilnærmingen som å bruke “funksjonen grener.” Dette skyldes at deres formål er å avgrense en (eller flere) spesifikke tillegg til koden.
2. En annen tilnærming er å gjøre alt ditt hovedarbeid i “herre” gren, gjør forpliktelser underveis. Når du er fornøyd med funksjonaliteten, lager du en filial innenfor den som du vil gjøre feilretting og lignende. Dette resulterer i flere av a “frigjør grenen” (vist nedenfor), når de slutter med utgivelsen. Det betyr også din “herre” gren er typisk den mest ustabile versjonen av koden din.

Bruk hvilken metode som passer best for deg

Den første tilnærmingen her er mer vanlig når du arbeider med git. Dens andre funksjoner (spesielt tagger) gjør det enkelt å merke et bestemt øyeblikksbilde av koden som “stabil.” Det gir seg også bedre til større, samarbeidsprosjekter. Men når du arbeider med dine egne personlige prosjekter, kan du gjerne bruke hvilken av disse som gir mest mening. Den gode tingen om å bruke git er at du fanger opp alle endringene, slik at du alltid kan gå tilbake og finne noe. Og organisering av prosjektet med git-grener gjør det litt enklere å gjøre.

Hvordan nærmer du grener i prosjektene dine? Bruker du dem til å eksperimentere, så søppel dem etterpå? Eller representerer de en detaljert historie om arbeidet ditt med prosjektet?

Gi oss beskjed nedenfor i kommentarene hvis du har noen smarte måter å håndtere grener i dine gitprosjekter!