Sådan fungerer Git — snapshots, branches og historik

Sådan fungerer Git — snapshots, branches og historik

The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.

How to read this visual

• Læs de tre kolonner fra venstre mod højre: Redigering, Commit, Deling.
• De fire banegrupper er en pipeline: arbejdsmappe til staging til lokalt til remote — hver pil flytter ændringen ét skridt nærmere på at være delt.
• Beslutningen »Har to personer ændret de samme linjer?« er den eneste forgrening, og begge udgange løber sammen i den delte historik til sidst.

Redigering og staging

»Udvikleren redigerer filer i arbejdsmappen« er den ikke-committede virkelighed — filer på disken, endnu ikke en del af historikken. »git add flytter ændringer ind i staging-området« er det bevidste mellemtrin: staging lader dig bygge et commit af udvalgte ændringer frem for alt det, du har rørt ved. Diagrammet skiller dem ad i hver sin banegruppe, fordi det er det todelte commit, der giver Git sin præcision.

At committe snapshottet

»git commit tager et snapshot af de stagede ændringer« er der, hvor en ændring bliver permanent. »Git gemmer committet med en pointer til sin forælder« gør grafen eksplicit — hvert commit, undtagen det første, navngiver committet før det, og det er dét, der gør historikken append-only og reviderbar. »Branch-pointeren flytter til det nye commit« fuldender handlingen: en branch er blot en pointer, så at committe på en branch er at flytte den pointer. Selve committet er ligeglad med, hvilken branch det ligger på.

At dele historikken

»git push sender commits til remoten« krydser fra banegruppen »Lokalt repository« over i »Remote repository« — det eneste sted, data forlader din maskine. »Remote-repositoryet registrerer den nye historik« er den delte kopi, og »Har to personer ændret de samme linjer?« modellerer merget: Git merger divergerende historikker automatisk, medmindre de samme linjer er ændret, og i så fald gør »Mergekonflikt — udvikleren løser den manuelt« den menneskelige beslutning eksplicit, før »Historikken er delt og opdateret« lukker forløbet.

Key relationships and takeaways

• Et commit er et fuldt snapshot kædet til sin forælder, og det er dét, der gør historikken til en append-only graf.
• En branch er en pointer til et commit, ikke en beholder med ændringer — og derfor er det billigt at oprette og skifte branch.
• Staging er det bevidste mellemtrin, der lader dig vælge, hvad et commit indeholder.
• Git er distribueret: alle har den fulde historik lokalt, og push/pull udveksler kun de manglende stykker.
• Konflikter er undtagelsen og ikke reglen — og sker de, er det et menneske, der løser dem eksplicit.

When to use this visual

• At lære snapshot-modellen fra sig til et team, der kun har brugt Git som en række kommandoer.
• At forklare branches, merges og konflikter ud fra pointer-modellen frem for udenadlærte kommandoer.
• At forankre en gennemgang af et teams commit- og branchingworkflow i, hvordan historikken faktisk er opbygget.

Sådan fungerer det

1. Tegn jeres teams reelle workflow

   Notér på boksene de kommandoer, jeres team faktisk bruger — feature-branches, pull requests, rebase over for merge — så diagrammet dokumenterer jeres praksis og ikke en lærebogs.

2. Tilføj jeres branch-model

   Indsæt rækker for feature-branch og main-branch i banegruppen »Lokalt repository«, og tegn merge-pilene mellem dem, så de ender i den delte historik.

3. Tegn porten med pull requests

   Tilføj en beslutning mellem det lokale push og registreringen på remoten: en gennemgang og et CI-tjek, der skal bestås, før branchen merges ind i main.

4. Tilføj vejene tilbage

   Tag fortryd-grenene med — revert et commit, amend en besked, reset til en tidligere tilstand — hver med sit eget eksplicitte udfald, for at komme tilbage er halvdelen af reel brug af Git.

Ofte stillede spørgsmål

Hvad er Git, og hvordan adskiller det sig fra anden versionsstyring?

Git er et distribueret versionsstyringssystem bygget på snapshots. Hvert commit gemmer et komplet billede af repositoryet plus en pointer til sin forælder frem for blot en liste over filændringer. Fordi hver udvikler har den fulde historik lokalt, virker de fleste operationer offline, og samarbejde er et spørgsmål om at udveksle commits med remotes.

Hvad er en branch i Git?

En branch er en flytbar pointer til et commit. Når du committer på en branch, rykker pointeren frem til det nye commit; selve committet ved ikke og er ligeglad med, hvilken branch det ligger på. Derfor er det øjeblikkeligt at oprette en branch, og derfor ændrer et skift mellem branches kun, hvilket snapshot din arbejdsmappe viser.

Hvorfor har Git et staging-område?

Staging-området lader dig bygge et commit bevidst. Du kan rette i flere filer, stage kun dem, der hører sammen, og committe netop det udvalg — og lade urelateret arbejde blive liggende ucommittet. Arbejdsmappen, staging-området og repositoryet er tre adskilte tilstande, og det er præcis den pipeline, diagrammet tegner.

Hvordan løser Git mergekonflikter?

Når to branches ændrer forskellige filer eller forskellige linjer, merger Git dem automatisk. Ændrer de de samme linjer, kan Git ikke gætte, hvilken version der er den rigtige, så den markerer konflikten og beder et menneske om at vælge. Konflikten er en beslutning og ikke en fejl — og derfor sender diagrammet den videre til et eksplicit løsningstrin, før historikken bliver delt.

Redigér dette diagram i QueryChart (FlowJam)

Åbn præcis det Git-lærred, du ser her, som dit eget diagram, omdøb banerne til jeres eget workflow, og tegn jeres egen historik.

Redigér dette diagram i QueryChart (FlowJam)