Da jeg endelig stoppede med “random branches” i Git

GitFlow er designet til større organisationer med tunge releases. Det kan virke imponerende, men i små teams ender det ofte som:

• Folk er i tvivl om hvor de skal branchen fra (develop? main? sidste release?).
• Der ligger gamle branches, ingen tør slette.
• Fejl bliver rettet forskellige steder og glemt i andre branches.

Trunk-based er kedeligt på den gode måde:

• Der er kun én sandhed: main.
• Alt nyt arbejde sker i små feature branches der hurtigt bliver merged ind.
• Du releaser ofte fra main (dagligt eller flere gange om ugen).

Min erfaring: Hvis I er færre end 8 udviklere og ikke har tunge versionskrav eller separate release-tog, så vælg en trunk-based variant. Du kan altid gøre det mere avanceret senere hvis det faktisk bliver nødvendigt.

3. Den simple model: main + korte feature branches

Her er den model jeg anbefaler små teams og studiegrupper at starte med.

3.1. Regler for main

main er hellig. Det betyder:

• Ingen direkte commits til main. Alt går gennem pull requests.
• main skal altid kunne deployes uden at smadre noget åbenlyst.
• Tests skal køre grønt på main (hvis I overhovedet har tests endnu).

Teknisk kan I låse det med branch protection i GitHub/GitLab, men det vigtigste er faktisk aftalen i teamet, ikke knappen.

3.2. Regler for feature branches

Alt nyt arbejde sker i korte feature branches:

• Branch ud fra main.
• Arbejd på én nogenlunde afgrænset ting.
• Lav PR når du er færdig med den ting (eller vil have feedback).

Eksempel på branch-navne:

• feature/login-form
• bugfix/navbar-overflow
• chore/update-deps-2024-05

Navngivning er ikke magisk, men folk læser branches oftere end de læser dokumentation, så du kan lige så godt hjælpe dem lidt.

3.3. Tommelfingerregler for størrelse

Kort er godt. Nogle enkle regler:

• PRs på under 300 linjer diff er til at overskue.
• Hold dig til én ændring pr. branch: “ny login-form” eller “ret bug i pagination” men ikke begge.
• Hvis PRen føles for stor, er den det nok. Del den op i 2 trin.

Og så commit-beskederne. Det her er ikke poetry slam, bare noget der kan læses om 3 måneder:

feat: tilføj validering til login-form
fix: ret mobil-navigation der overlapper logo
chore: bump react til 18.3

Hvis du gerne vil træne det der med at skrive tydelig dokumentation og små afgrænsede ændringer, så hænger det ret godt sammen med at skrive en README, der faktisk bliver læst.

4. Rebase vs merge: vælg én standard

Her bliver mange små teams uvenner med Git uden at forstå hvorfor.

Du har to typiske flows for at holde din feature branch up-to-date med main:

• Merge: git merge main inde i din feature branch.
• Rebase: git rebase main inde i din feature branch.

Begge kan fungere. Problemet opstår når nogle rebaser, andre merger, og I ikke har en regel om hvad der er ok efter at en branch er delt med andre.

4.1. Sikkert default for små teams

Jeg plejer at foreslå denne enkle kontrakt:

• Inden PR: Du må gerne bruge rebase på din egen branch.
• Efter PR er oprettet: Brug git merge main for at opdatere din branch.
• På main: Brug “Squash and merge” eller “Rebase and merge” i UIet. Ingen normale merge commits.

Begrundelsen er simpel: Rebase omskriver historikken. Det er fint, så længe det kun er din egen lokale historie. Men det bliver rodet, når andre har hentet din branch, eller når der allerede ligger en PR med kommentarer og referencer til specifikke commits.

4.2. Et konkret rebase-flow før PR

Et trygt flow kan se sådan her ud:

# du står på main
git pull origin main

git checkout feature/login-form
git rebase main
# løs eventuelle conflicts

git push --force-with-lease

--force-with-lease er en lidt mere sikker version af --force, fordi den tjekker at du ikke overskriver andres arbejde på fjern-branchen.

5. PR-tjekliste: hvad skal være på plads før review?

Nu til den del der reelt sparer jer tid: en lille pull request tjekliste alle kan følge.

5.1. Copy/paste tjekliste til dit repo

Lav en fil .github/pull_request_template.md i repoet og smid noget i stil med det her ind:

## Hvad ændrer denne PR?
-

## Tjek før du beder om review
- [ ] Branchen er opdateret med `main`
- [ ] Ingen debug logs / commented-out kode
- [ ] Tests kører lokalt (eller der er en note om hvorfor ikke)
- [ ] Eventuelle database migrations er kørt lokalt
- [ ] Konfig / env-vars er dokumenteret
- [ ] Screenshots er vedhæftet ved UI-ændringer

## Noter til reviewer
-

Det ser banalt ud, men tvinger lige hjernen til at stoppe op et halvt minut før du trykker “Create pull request”. Det er ofte nok til at fange “hov, jeg glemte at fjerne den console.log”.

5.2. Hvad skal revieweren kigge efter?

Som reviewer kan du bruge samme tjekliste, men kigge på den fra modtager-siden:

• Forstår jeg hvad PRen gør ud fra beskrivelsen?
• Er ændringen så afgrænset at jeg faktisk kan reviewe den ordentligt?
• Er der åbenlyse “hvis det her fejler i produktion, gør det så rigtig ondt?” steder, der mangler tests eller logging?

Du kan godt være flink og grundig på samme tid. Det hjælper også din egen læring, især hvis du stadig føler dig lidt ny i test og kvalitet.

6. Release-rytme: små releases uden drama

Branching strategi hænger tæt sammen med hvordan I releaser.

Med trunk-based + korte feature branches vil jeg anbefale:

• Små, hyppige releases: hellere 3 små om ugen end én stor hver tredje uge.
• En enkel regel: “Hvis det ligger på main og tests er grønne, må det komme med i næste release”.
• Hotfix branches: ved akutte fejl laver I hotfix/... direkte fra main, får den igennem review, deployer og er færdige.

Hvis I har CI/CD, kan I automatisk deploye main til staging og have en knap til produktion. Hvis ikke, så er release-ritualet bare et par manuelle kommandoer, men stadig med samme simple regel: alt sker fra main.

Det spiller i øvrigt fint sammen med at have en simpel deployment-struktur som dem vi tit snakker om i kategorien deployment og drift.

7. Onboarding: 30 minutters intro til jeres Git-setup

En god test af din branching strategi er: Kan en ny person forstå den på en halv time, uden whiteboard-diagrammer?

7.1. Lav en “team-kontrakt” i repoet

Jeg kan godt lide at have en docs/git-workflow.md med noget i den her stil:

# Git workflow for dette repo

## Branches
- main: altid deployable, ingen direkte commits
- feature/*: nye features
- bugfix/*: fejlrettelser
- hotfix/*: akutte fejl i produktion

## Sådan arbejder du på en opgave
1. `git checkout main` og `git pull`
2. `git checkout -b feature/kort-beskrivende-navn`
3. Lav dine ændringer, commit med små, meningsfulde beskeder
4. Opdater din branch med `main` ved behov
5. Opret PR når opgaven er afgrænset og klar til review

## Rebase vs merge
- Før PR: du må gerne rebase din egen branch
- Efter PR: brug merge fra main

## Pull requests
- Brug PR-templaten
- Små ændringer, tydelig beskrivelse

Pointen er ikke at have 100 regler, men at alt står et sted, så I slipper for “jeg troede vi gjorde sådan her” i Slack-tråde.

7.2. Gå workflowet igennem som en mini-øvelse

Når en ny person starter, kan du bruge 30 minutter på:

1. At clone repoet.
2. At lave en lille test-branch, fx feature/add-readme-note.
3. At lave en bitte ændring (tilføje en linje i README).
4. At lave en PR med jeres template.
5. At lave et review sammen og merge den.

Så har personen prøvet den fulde cyklus: branch, commit, PR, review, merge. Det er meget mere værd end at høre om GitFlow på teori-plan. Især hvis de kommer fra mindre solo-projekter og begynderprojekter, hvor man ofte bare har commit’et direkte til main.

8. En lille huskeregel til jeres næste Git-diskussion

Jeg plejer at bruge den her sætning når Git-diskussioner løber lidt af sporet:

“Hvis vores branching strategi gør det svært at lave en lille ændring og få den i produktion hurtigt, så er strategien for tung.”

Den dag vi fjernede halvdelen af vores branches og gjorde main til det eneste “sande” udgangspunkt, faldt mit Git-stressniveau markant. Jeg savner ikke de lange aftener med mærkelige merge commits og forældede release-branches. Jeg savner til gengæld stadig ikke den gang jeg ødelagde hele historikken med et forkert rebase og lærte på den hårde måde hvorfor man skal have nogle fælles regler.

Så næste gang I overvejer en fancy branching model, kan I måske starte med det simple setup her, se hvad der faktisk sker i jeres hverdag, og kun justere derfra hvis I har et konkret problem at løse.