Git: Branching-strategier, rebase og commit-hygiene i praksis

Git er verktøyet jeg bruker mest uten å tenke over det. Hver eneste dag, i hvert prosjekt — fra Tuli sin backend i Go, til denne porteføljen i Next.js, til eksperimentelle scripts jeg skriver for å automatisere ting. Men det tok tid før jeg brukte Git bevisst. I starten var det git add ., git commit -m "fix", git push — og historikken var en uleselig strøm av meningsløse meldinger.

Nå behandler jeg git-historikken som dokumentasjon. Ikke for verktøyets skyld, men fordi fremtidens meg — og folk jeg jobber med — fortjener å forstå hvorfor en endring ble gjort, ikke bare hva som ble endret.

Commit-meldinger som forteller en historie

Den viktigste vanen jeg har bygd er å skrive commit-meldinger med intensjon. Jeg følger Conventional Commits-formatet, ikke fordi det er trendy, men fordi det tvinger meg til å kategorisere endringer:

feat(auth): add JWT refresh token rotation
fix(api): handle nil pointer in user lookup
refactor(db): extract connection pooling to shared package
docs(readme): update deployment instructions for Cloud Run
chore(deps): bump go.mod dependencies to latest patch

Prefikset (feat, fix, refactor, docs, chore) gjør to ting. Det tvinger meg til å tenke over typen endring jeg gjør. Og det gjør historikken skannbar — jeg kan raskt finne alle features som ble lagt til mellom to releaser, eller alle bugfikser i en bestemt modul.

Selve meldingen beskriver hva og hvorfor, ikke hvordan. "Add JWT refresh token rotation" forteller meg nøyaktig hva som endret seg. Koden viser hvordan.

Branching-strategi: Enkel for solo, strukturert for team

Når jeg jobber alene — som på denne porteføljen eller personlige prosjekter — holder jeg det enkelt. main er alltid deploybar. Feature-arbeid skjer på korte branches som lever timer eller dager, ikke uker:

git checkout -b feat/blog-filtering
# ... jobbe, committe, teste ...
git checkout main
git merge --no-ff feat/blog-filtering
git branch -d feat/blog-filtering
git push origin main

--no-ff (no fast-forward) er viktig. Det lager en merge-commit som tydelig markerer at en feature ble integrert. Uten den ville historikken vært en flat linje der det er umulig å se hvor en feature starter og slutter.

I teamarbeid, som i Tuli, bruker vi en mer strukturert tilnærming. main er produksjon. Feature-branches lages fra main, og pull requests krever review før merge. Vi squasher ikke automatisk — hver commit i en PR skal være meningsfull og selvstendig.

Interaktiv rebase: Rydd før du deler

Rebase er der magien skjer. Mens jeg jobber lokalt, committer jeg ofte og rotete — "wip", "fix test", "oops". Det er helt greit. Men før jeg pusher eller lager en PR, rydder jeg opp med interaktiv rebase:

git rebase -i HEAD~5

Dette åpner en editor der jeg kan squashe, redigere, omorganisere og slette commits. Resultatet er en ren historikk der hver commit er en logisk enhet som kompilerer og passerer tester.

Rebase vs. merge er en evig debatt. Min tilnærming er pragmatisk: rebase lokale commits for å holde historikken ren, men aldri rebase noe som er pushet til en delt branch. Rewrite av delt historikk skaper kaos.

Git-aliaser som sparer tid

Min .gitconfig har aliaser jeg bruker daglig:

[alias]
  s = status -sb
  lg = log --oneline --graph --decorate -20
  co = checkout
  cm = commit -m
  ca = commit --amend --no-edit
  df = diff --stat
  unstage = reset HEAD --
  last = log -1 HEAD --stat

git lg er favoriten — den viser en kompakt, visuell graf av de siste 20 committene med branch-dekorasjoner. git s gir en kort status uten støy. git ca amender siste commit uten å endre meldingen — perfekt for "glemte å legge til den filen"-situasjoner.

Ting jeg har lært på den harde måten

Aldri force-push til `main`. Jeg gjorde det én gang, overskrev en kollegas commits, og brukte en time på å fikse det med reflog. Leksjon lært.

Commit ofte, push gjennomtenkt. Lokale commits koster ingenting. Push er en beslutning om å dele arbeid med andre. Behandl dem forskjellig.

Skriv commit-meldinger i presens imperativ. "Add feature" ikke "Added feature" eller "Adds feature". Det matcher Gits egne meldinger ("Merge branch...") og leser bedre i loggen.

Bruk `.gitignore` fra dag én. Ingenting er verre enn å committe node_modules, .env-filer eller IDE-konfigurasjon. Lag en skikkelig .gitignore før du skriver første linje kode.

Oppsummering

Git er mer enn et backup-verktøy. Med gode commit-meldinger, en konsistent branching-strategi, og disiplinen til å rydde opp med rebase, blir historikken en verdifull ressurs. Den forteller historien om prosjektet — ikke bare hva som ble endret, men hvorfor.

Start med Conventional Commits, bruk --no-ff for merges, og rydd opp lokale commits med interaktiv rebase. Resten er erfaring og konsistens.