Etter dette gir Git endelig mening

De fleste av oss har et forhold til Git som minner litt om forholdet til en gammel bil: den starter som regel, vi kjører den hver dag, og vi har en vag følelse av at vi ikke bør røre noe under panseret. Vi kan add, commit opush på autopilot, men i det øyeblikket noe går sidelengs — en merge conflict, en detached HEAD, en commit som forsvant — får vi den samme klumpen i magen som da vi var nye.

Det rare er at Git egentlig ikke er komplisert. Den er bare dårlig forklart. De fleste lærer kommandoene før de lærer modellen, og da blir alt en serie magiske besvergelser man memorerer i feil rekkefølge. Så la oss gjøre det motsatt. La oss bygge den mentale modellen først, og så henger kommandoene seg på av seg selv.

Hva Git egentlig er

Tenk på prosjektet ditt som et verksted. Ikke et abstrakt et — et ekte et, med en arbeidsbenk, verktøy og halvferdige ting liggende rundt. Du jobber, du fikser, du roter til, du rydder. En helt vanlig dag.

Git er loggboken som henger på veggen i dette verkstedet. Hver gang du har gjort noe du er fornøyd med, tar du et bilde av hele benken — ikke bare av tingen du jobbet med, men av alt, slik det ser ut akkurat nå — og limer det inn i loggboken med en liten lapp om hva du gjorde. Det bildet er en commit.

Og her kommer det viktigste å forstå: Git lagrer ikke endringene dine. Git lagrer øyeblikksbilder. Hver commit er et komplett snapshot av hele prosjektet på det tidspunktet. Det føles kanskje sløsete, men det er nettopp dette som gjør Git så trygg å bruke: ingenting du har committet kan egentlig gå tapt, fordi hvert eneste bilde ligger der fremdeles. Du flytter deg bare mellom dem.

De tre rommene

Når du jobber, befinner endringene dine seg alltid i ett av tre «rom». Skjønner du disse tre, har du skjønt nitti prosent av Git.

Arbeidsmappen er selve benken. Det er filene slik de ligger på maskinen din akkurat nå — rotete, halvferdige, midt i en tanke. Når du redigerer en fil i editoren, skjer det her.

Staging-området (også kalt the index) er det lille bordet ved siden av benken hvor du legger akkurat de tingene du vil ha med på neste bilde. Du har kanskje fikset tre ting, men bare to av dem hører sammen. Da legger du de to på staging-bordet og lar den tredje ligge igjen på benken. Dette er hva git add gjør — det er ikke «lagre», det er «velg ut til neste bilde».

Repositoriet er selve loggboken, den som ligger trygt i .git-mappen. Når du sier git commit, tar Git bilde av alt som ligger på staging-bordet og fester det permanent i loggboken.

Så den daglige rytmen er bare denne reisen: benk → staging-bord → loggbok.

git status          # Hva ligger hvor akkurat nå?
git add fil.php     # Legg fil.php på staging-bordet
git add .           # Legg alt på staging-bordet
git commit -m "Fikset prisberegning i kassen"

Et lite råd som har spart meg for mye: skriv commit-meldingen som om noen spør «hva gjør denne endringen?». «Fikset prisberegning i kassen» forteller en historie. «fix», «stuff» og «asdf» gjør deg til en fremmed i din egen loggbok tre måneder senere.

Branches — eller: parallelle verksteder

Her er triksen som virker som svart magi helt til den klikker, og så lurer du på hvorfor noen lot det høres skummelt ut.

En branch er bare en lapp som peker på en commit. Det er alt. Det er ikke en kopi, ikke en mappe, ikke et nytt univers — bare en gul Post-it-lapp som henger på et bestemt bilde i loggboken og sier «her er jeg».

Standardlappen heter som regel main. Når du lager en ny branch, river du bare av en ny lapp og henger den på samme bilde:

git switch -c ny-funksjon   # Lag og hopp til en ny branch

Nå kan du jobbe i fred. Du tar nye bilder, loggboken vokser, og ny-funksjon-lappen flytter seg framover for hvert bilde du tar — mens main-lappen blir liggende rolig der den var. Det fine er at du når som helst kan hoppe tilbake til main med git switch main, og hele benken stiller seg om til slik den så ut der. De to arbeidene forstyrrer ikke hverandre.

Dette er hele grunnen til at man bruker branches: du kan eksperimentere vilt, prøve noe som kanskje ikke funker, og hvis det går skikkelig galt — kast lappen, og det er som om det aldri skjedde. main aner ingenting.

HEAD, forresten, er bare Git sin måte å si «hvilken lapp ser du gjennom akkurat nå». Når du hører «detached HEAD», betyr det bare at du ser på et bilde direkte uten at en lapp henger der. Ikke farlig. Heng på en lapp, så er du tilbake i kjent farvann.

Når flere jobber i samme verksted

Så langt har alt skjedd på din egen maskin. Git er nemlig fullstendig lokal — du trenger verken internett eller en server for å committe. Men poenget med Git er som regel at flere skal jobbe sammen, og da trenger vi en felles loggbok et sted ute i verden. Den kaller vi en remote, og den ligger gjerne på GitHub, GitLab eller lignende. Som oftest heter den origin.

Rytmen blir da:

git clone <url>   # Hent ned hele verkstedet for første gang
git pull          # Hent ned det andre har gjort siden sist
git push          # Send dine bilder opp til den felles loggboken

pull er «hent og slå sammen det nyeste fra fellesskapet». push er «legg mine bilder i den felles boken så andre ser dem». En god vane er å pull før du begynner på noe nytt, så du bygger videre på det ferskeste.

Når funksjonen din er ferdig, er det her pull request kommer inn — en høflig forespørsel om å få sine bilder inn i main. «Jeg har gjort dette, vil noen se over det før vi limer det inn i hovedboken?» Det er ikke en Git-kommando i seg selv, men en arbeidsform som GitHub og resten har bygget rundt akkurat denne flyten. Det er her kollegaen din fanger den tabben du selv var for nær til å se.

Merge conflicts — ikke en feil, bare en samtale

Ordet «conflict» får folk til å svette, men en merge conflict er ikke at noe er ødelagt. Det er Git som er ærlig: «Dere to har endret nøyaktig samme linje på hver deres måte, og jeg nekter å gjette hvem som har rett.»

Det er faktisk høflig av den. Alternativet — at den bare valgte én av dere i det stille — hadde vært langt verre.

Når det skjer, markerer Git de aktuelle stedene i fila slik:

<<<<<<< HEAD
prisen er 100 kroner
=======
prisen er 120 kroner
>>>>>>> ny-funksjon

Du sletter markørene, bestemmer hva som faktisk skal stå der, lagrer, og git add + git commit. Ferdig. Konflikten var aldri et problem med Git — det var to mennesker som var uenige om en linje, og Git ga deg rommet til å rydde opp i det.

Når du vil angre

Den vanligste grunnen til at folk er redde for Git, er frykten for å ødelegge noe. Men husk øyeblikksbildene: alt som er committet, ligger der fremdeles. Her er de tre du trenger oftest:

git restore fil.php          # Kast endringer i arbeidsmappen, gå tilbake til siste commit
git restore --staged fil.php # Ta fila av staging-bordet (men behold endringene)
git commit --amend           # Skriv om den siste commiten (typisk: fiks meldingen)

Og når alt føles tapt — en branch du trodde du slettet, en commit som forsvant — finnes git reflog. Den fører logg over hvor HEAD har vært de siste dagene, og fungerer som et sikkerhetsnett under sikkerhetsnettet. Veldig få ting i Git er faktisk borte for godt. Det er verdt å puste rolig ut og vite.

Et par vaner som gjør resten enkelt

Etter mange år med Git i hendene er det egentlig bare noen få ting jeg skulle ønske noen sa til meg tidlig:

Commit ofte, og hold hver commit til én tanke. Små, hyppige bilder er lettere å forstå og lettere å angre enn ett stort uoversiktlig et på fredag ettermiddag.

Bruk branches for alt som ikke er trivielt, og la main være stedet som alltid funker. Det koster ingenting å lage en branch, og den friheten det gir til å prøve ting, er hele poenget.

git status er din beste venn. Når du er usikker på hva som skjer — og det blir du — er det første spørsmålet alltid: hva ligger hvor akkurat nå? Status svarer.

Og til slutt: ikke vær redd. Git er bygget av folk som var livredde for å miste arbeid, og hele systemet er gjennomsyret av den forsiktigheten. Det er omtrent det tryggeste verktøyet du har på maskinen. Jo bedre du forstår modellen — øyeblikksbildene, de tre rommene, lappene — jo mer føles det som et verksted du eier, og ikke en bil du ikke tør å åpne panseret på.

Neste gang noe går sidelengs, prøv å ikke google panikkartet. Spør heller: hvilket rom er jeg i, og hvilket bilde peker lappen min på? Som regel løser svaret seg selv.