Sådan bruges Git-grene til at strukturere dit programmeringsprojekt

Film og tv fremstiller programmering som en hektisk aktivitet Hollywood Hacks: Den bedste og værste hacking i film Hollywood Hacks: Den bedste og værste hacking i film Hollywood og hacking går ikke sammen. Selvom hacking i det virkelige liv er hårdt, involverer filmhackning ofte bare at bankes væk på et tastatur, ligesom dine fingre går i stil. . En bombers timer tæller ned, og den nørrede sidekick, der var en byrde indtil det tidspunkt fungerer feberligt på en bærbar computer. Koden flyver hen over skærmen, indtil hun rammer den sidste returtast med en tilfredsstillende klapre! Timeren stopper, og alt er i verden igen. Men programmering er ikke sådan. Det inkluderer designdokumenter, UI-mock-ups og kodevurderinger. Og mere end noget andet involverer det prøve og fejl, især hvis du er en nybegynder (som mig).

Nu er du muligvis allerede overbevist om værdien af ​​at holde dine kodningsprojekter under kildekontrol Hvad er Git og hvorfor du skal bruge versionskontrol, hvis du er en udvikler Hvad er Git og hvorfor du skal bruge versionskontrol, hvis du er en udvikler Som webudviklere er det meget af tiden, vi har tendens til at arbejde på lokale udviklingswebsteder, og bare uploade alt, når vi er færdige. Dette er fint, når det bare er dig, og ændringerne er små,…. At overføre al denne prøve og fejl til dit arkiv vil gøre et stort og urydigt projekt med mange revisioner. De fleste af de forpligtelser, du foretager, vil indeholde ting, der er ødelagt, så hvorfor gemme det? Git afdeling -funktionen kan hjælpe med at holde al denne rodede kode væk fra de ting, du ved, fungerer.

I denne artikel skal vi se på, hvad forgrening din kode betyder, hvordan du gør det og måder at administrere opdateringer til “vigtigste” afdeling.

Oprettelse af en Git filial

Vi har lært fra vores introduktion til kildekontrol Administrer din filversion som en programmerer med Git Administrer din filversion som en programmerer Med Git Programmerere oprettede versionskontrolsystemer (VCS) for at løse filversionskontrolproblemer. Lad os se på det grundlæggende i versionskontrol ved hjælp af det øverste system i dag, Git. at du kan oprette et nyt lager med følgende kommando i en terminal:

git init

Når du gør dette, opretter det et skjult bibliotek i din aktuelle sti, kaldet “.git.” Hvis du ikke kan se det, kan du læse nogle af vores tidligere artikler om visning af skjulte Den nemme måde at vise skjulte filer og mapper i Windows 10, 8.1 og 7 Den nemme måde at vise skjulte filer og mapper i Windows 10, 8.1 og 7 Brug for at se skjulte filer og mapper i Windows? Sådan vises dem i Windows 10, 8.1 og 7, så intet er skjult for dig. filer Skjul & find enhver fil på Mac OS X Skjul & find enhver fil på Mac OS X Der er ingen ligefrem måde at hurtigt skjule eller afsløre skjulte filer på Mac OS X, som det er på Windows - men det er muligt. . Dette bibliotek indeholder alle de nødvendige oplysninger for at bevare revisionshistorikken for dine filer. Når du har indstillet din filhåndtering til at vise skjulte filer, kan du åbne .git-mappen og se et antal undermapper. En af disse kaldes “ref” (vist på billedet herunder) og dets “hoveder” undermappe indeholder lister over alle filialer i dit projekt. Fra starten har du bare en, dubbet “mestre.”

Refs-biblioteket fører en fortegnelse over grenen, men ikke grenen i sig selv. I det mindste ikke den filial, du er bruger i øjeblikket. Disse filer opbevares i arbejdsmappen (“~ / Temp / post-programmering-git-filial” i ovenstående eksempel), så du kan få adgang til dem på en normal måde. Ved at gøre nøjagtigt det, opretter vi vores første fil (navngivet “første-file.txt”) i arbejdsmappen, dvs.. uden for .git-biblioteket. Tjek dette ved at bruge de pålidelige kommandoer fra den forrige introduktion til git-artiklen Administrer din filversion som en programmerer med Git Håndter din filversion som en programmerer med Git Programmerere oprettede versionskontrolsystemer (VCS) for at løse filversionskontrolproblemer. Lad os se på det grundlæggende i versionskontrol ved hjælp af det øverste system i dag, Git. :

Vi kan nu se, at arbejdsmappen har to filer, den, vi har forpligtet, og en, der oprettes automatisk af git (den indeholder den meddelelsesmeddelelse, vi lige har indtastet).

Lad os nu oprette en ny gitgren kaldet “test”:

test af git branch

Tjek filialen og arbejde i den

Vi kan udstede ovenstående kommando uden navn for at få en liste over alle grene samt hvilken vi i øjeblikket bruger (dvs. hvilken er “tjekket ud”):

Hvis vi nu undersøger mappestrukturen, får vi se “.git / ref / hoveder” har nu to filer, en hver til “mestre” og “test.”

Hver af disse er en liste over de forpligtelser, der omfatter filialen. For eksempel, hvis vi undersøger “mestre” gren med “git log” kommando, kan vi se en linje for hver af de forpligtelser, der er foretaget til denne gren.

Processen med “tjekker ud” en gren betyder, at ændringer, du foretager til filer, vil være en del af den gren, men ikke andre grene. Antag f.eks. At vi tjekker testgitgrenen med følgende kommando:

test af git checkout

Derefter tilføjer vi en tekstlinje til first-file.txt, selvfølgelig forpligter vi den bagefter. Hvis du skifter tilbage til mastergrenen, finder du, at filen stadig er tom (filen kat kommando viser en fils indhold i terminalen):

Men vender tilbage til “test” filial, har filen stadig den tilføjede tekst:

Men alt, hvad vi nogensinde ser i det korrekte bibliotek, er den eneste fil “første-file.txt.” Hvor er så disse to alternative versioner af den samme fil? .Git-biblioteket tegner sig for disse ændringer, men ikke på den måde, du kunne forvente.

Hvordan Git gemmer ting

Hvis du skulle undersøge et lager for andre versionskontrolsystemer som Subversion, ville du opdage, at de opretholder en kopi pr. Revision for hver enkelt fil. Dette betyder, at hvis du har et arkiv med en fil, så oprettes to grene, repoen indeholder to forskellige kopier af den fil. Faktisk bruger du faktisk “svn-kopi” som kommandoen til at oprette en gren i Subversion! På den anden side fungerer git på konceptet med “ændringer.”

Outputet fra ovenstående fortæller os hele indholdet af “bagagerum” (SVNs version af “mestre”) er blevet kopieret. Et kig i en filhåndtering bekræfter dette:

Det “.git / objekter” biblioteket er det, der indeholder alle disse små ændringer, og hver enkelt spores med et ID. For eksempel i nedenstående billede ser du filer med lange ID-stilnavne. Hver lever i en mappe navngivet med to hexadecimale tegn (8c og 8d under).

Sammen udgør disse mappe- og filnavne ID'et til en bestemt ændring (faktisk en SHA1-hash). Du kan udforske deres indhold vha git cat-fil kommando. Baseret på deres ændrede datoer kan vi se den første begyndelse “8d” kom først, og det viser intet. Mens den starter “8c” indeholder den tekstlinje, vi føjede til filen i “test” afdeling.

Takeaway er, at git grene (inklusive standarden “mestre”) er ikke adskilt “mapper” der indeholder kopier af filer. Snarere er det lister over ændringer, der er foretaget i filer over tid. Dette er mere effektivt lagringsmæssigt, men resultatet er det samme. Alt, hvad du laver (bryder?) I en git-gren, forbliver der, indtil du fletter det sammen.

Strategier for fusionering tilbage til hovedgrenen (at slette eller ikke slette?)

Antag, at du havde et eksisterende projekt med et antal filer, som du derefter forgrenede sig til “test,” og gjorde noget arbejde med det. Nu vil du få disse ændringer tilbage til “mestre” afdeling. Du kan gøre med følgende fra “mestre” afdeling:

test af git merge

Forudsat at der ikke er konflikter, the lave om bestående af den nye tekst vil være anvendt til “mestre.” Resultatet er “første-file.txt” vil være identisk i begge grene. Alligevel var der aldrig rigtig alternative versioner af filen.

Nu kommer spørgsmålet, hvad skal man gøre med filialen? Der er to fælles strategier for håndtering af filialer.

1. Den ene er at holde en git gren ligesom “test” at lege rundt i (vist ovenfor). Du prøver nogle ting ud, og hvis du kan få dem til at fungere, flettes ændringerne tilbage i “mestre.” Så kan du afslutte arbejdet med den gren eller endda slippe af med det helt. Dette betyder din “mestre” er den mest stabile version af koden, fordi den kun skal indeholde ting, du ved, der fungerer. Du kan også tænke på denne tilgang som ved hjælp af “har grene.” Dette skyldes, at deres formål er at forfine en (eller flere) specifikke tilføjelser til koden.
2. En anden tilgang er at gøre alt dit vigtigste arbejde i “mestre” gren, gør forpligtelser undervejs. Når du er tilfreds med funktionaliteten, opretter du en gren inden for den, som du vil lave fejlrettelse og lignende. Dette resulterer i mere af en “frigør gren” (vist nedenfor), da de slutter med frigivelsen. Det betyder også din “mestre” gren er typisk den mest ustabile version af din kode.

Brug den metode, der er bedst for dig

Den første tilgang her er mere almindelig, når man arbejder med git. Dens andre funktioner (specifikt tags) gør det nemt at markere et bestemt øjebliksbillede af koden som “stabil.” Det egner sig også bedre til større samarbejdsprojekter. Men når du arbejder på dine egne personlige projekter, er du velkommen til at bruge den af ​​disse der giver dig mest mening. Det fantastiske ved at bruge git er, at du fanger alle dine ændringer, så du altid kan gå tilbage og finde noget. Og at organisere dit projekt med gitgrene gør det lidt lettere at gøre.

Hvordan nærmer du dig filialer i dine projekter? Bruger du dem til at eksperimentere og derefter skrald dem bagefter? Eller repræsenterer de en detaljeret historie af dit arbejde med projektet?

Fortæl os det nedenfor i kommentarerne, hvis du har nogle smarte måder at håndtere grene i dine git-projekter på!