Slik bruker du Git branches til å jobbe parallelt uten kaos

Git løser et veldig konkret problem: flere skal endre på den samme koden, ofte samtidig, uten å tråkke hverandre på tærne. Nøkkelen til å få dette til i hverdagen er å bruke branches på en bevisst og enkel måte.

I denne artikkelen ser vi på en praktisk tilnærming til branches: hvordan du navngir dem, hvordan du oppretter dem, hvordan du unngår klassiske konflikter og hvordan du får en ryddig flyt fra idé til ferdig endring i main.

Hva en branch egentlig er i Git

En branch i Git er bare en peker til en bestemt commit, som beveger seg fremover etter hvert som du gjør nye commits. Du kan se på det som en egen tidslinje for endringene dine.

Poenget er at du trygt kan eksperimentere på en branch uten å ødelegge det som er på main. Når du er fornøyd, kan du flette endringene inn igjen med en merge eller ved å rebase.

En enkel og nyttig branch-strategi

Det finnes mange avanserte Git-modeller, men for de fleste team er det nok med en enkel struktur: én stabil hovedgren, og korte arbeidsgrener til hver konkret endring.

En typisk struktur kan se slik ut:

• main: den stabile grenen som alltid skal være kjørbar
• feature/…: nye funksjoner eller større forbedringer
• bugfix/…: feilrettinger som ikke kan gå rett på main
• chore/…: småting som oppdatering av avhengigheter eller verktøyoppsett

Navngivning som faktisk hjelper deg

Gode branchnavn gjør det enklere å forstå historikken og samarbeide. Prøv å gjøre navnet beskrivende, men ikke romanutdrag. Det bør være mulig å se hva som skjer uten å åpne koden.

Noen mønstre som ofte fungerer:

• feature/abonnement-side
• bugfix/login-nullpointer
• chore/oppdater-eslint-konfig
• feature/1234-profilbilde-opplasting(hvis dere bruker oppgavenummer)

Grunnleggende kommandoer du faktisk bruker daglig

La oss ta en vanlig arbeidsflyt fra lokal main til ferdig branch:

• Oppdater main lokalt:
  git checkout main
git pull
• Lag en ny branch fra oppdatert main:
  git checkout -b feature/abonnement-side
• Jobb, legg til filer og commit:
  git add .
git commit -m "Lag enkel abonnement-side med dummy-data"
• Push branchen til server:
  git push -u origin feature/abonnement-side

Etter første push holder det med git push, siden -u allerede har satt opp sporingen mot origin.

Hold branchene korte og målrettede

En av de vanligste kildene til frustration er at en branch lever i ukevis. Da endres main hele tiden, konflikter bygger seg opp og det blir tungt å få ting inn igjen.

Prøv i stedet å sikte på små, avgrensede endringer som kan merges relativt raskt. Hvis oppgaven er stor, del den i mindre deler som hver kan gi en synlig forbedring eller teknisk framgang.

Unngå stygge merge-konflikter

Konflikter er ikke farlige, men de blir mye mer krevende hvis branchen er gammel eller gigantisk. En enkel vane er å jevnlig hente inn endringer fra main inn i branchen din.

En trygg måte som mange trives med er vanlig merge:

• git checkout main
• git pull
• git checkout feature/abonnement-side
• git merge main

Hvis det oppstår konflikter, løser du dem i editoren, kjører testene dine og committer merge-commiten. Da er branchen din oppdatert med siste endringer fra main.

Når bør du bruke rebase i stedet for merge

Rebase gir en ryddigere historie ved å «flytte» commits til toppen av main i stedet for å lage merge-commits. Det kan være nyttig før du åpner en pull request, eller rett før du skal merge.

En vanlig sekvens kan være:

• git checkout feature/abonnement-side
• git fetch origin
• git rebase origin/main

Hvis det oppstår konflikter, stopper rebase midlertidig. Du løser konflikten, kjører git add på de filene som er fikset, og fortsetter med git rebase --continue.

Branch og pull request som arbeidsenhet

I mange team er pull requesten selve «billetten» for en endring. En branch tilsvarer da én konkret pull request, med en tydelig beskrivelse av hva som endres og hvorfor.

For å gjøre dette smidig, er det lurt å:

• bruke et beskrivende branchnavn som gjenbrukes i tittelen
• skrive kort hva problemet var og hvordan du har løst det
• lenke til eventuell oppgave i prosjektverktøyet
• nevne om det er noe som bør testes ekstra nøye

Typiske feil og hvordan du fikser dem

Noen klassikere dukker opp i de fleste team før eller siden. Heldigvis er de ofte enkle å rette når du vet hva som skjedde.

1. Du committet rett på main lokalt
Lag en branch fra den commiten og flytt endringen:

• git branch feature/glemt-branch
• git reset --hard origin/main
• git checkout feature/glemt-branch

2. Du startet branchen fra en gammel main
Rebase eller merge inn siste main før du åpner pull request:

• git fetch origin
• git rebase origin/main eller git merge origin/main

3. Du havnet i en halvferdig rebase
Hvis det blir rotete, kan du avbryte:

• git rebase --abort

En enkel sjekkliste før du sletter en branch

Når en branch er flettet inn i main, er det ryddig å slette den både lokalt og på server. Før du gjør det, er det greit å dobbeltsjekke noen ting.

• Endringen er merget inn i main eller tilsvarende gren
• Testene for prosjektet går gjennom
• Branch-navnet og pull requesten forteller historikken godt nok
• Ingen andre er i gang med videre arbeid på akkurat den branchen

Deretter kan du slette lokalt med git branch -d feature/abonnement-side, og på server med git push origin --delete feature/abonnement-side hvis dere ønsker det.

Start enkelt og gjør vanene faste

Du trenger ikke avanserte Git-strategier for å få stor gevinst. Enkelt mønster, gode navn og korte levetider på branches tar deg langt, spesielt i små og mellomstore team.

Begynn med å alltid opprette en branch fra oppdatert main, holde endringen avgrenset, og hente inn nye endringer før du ber om gjennomgang. Det gir mindre friksjon, færre konflikter og en mer forståelig historikk for alle som kommer etter deg.