Git-workflow: gids voor feature branches en pull requests

Een degelijke git workflow is de goedkoopste investering die je in de codebase van een team kunt doen. Alleen werkend levert alles rechtstreeks naar main pushen geen problemen op; maar zodra twee mensen aan hetzelfde bestand komen, blijft de vraag wie wat wanneer wijzigde onbeantwoord. Een flow gebouwd op feature branches en pull requests bestaat precies om die chaos te voorkomen: elk stuk werk groeit op zijn eigen branch, en de hoofdbranch breekt nooit voordat iemand de wijziging heeft gezien.

In deze gids beschrijf ik een eenvoudige maar gedisciplineerde flow die werkt voor elk soort team, van Metin2-serverprojecten tot Laravel-webapps. Het doel is niet om flitsende commando's uit het hoofd te leren; het is werken in het besef van wat je doet en waarom.

Waarom een feature branch?

De hoofdbranch (main of master) moet altijd uitbrengbaar zijn. Alles wat je eruit checkt, moet kunnen builden en draaien. Je beschermt dat door onafgemaakt werk buiten de hoofdbranch te houden. Elke nieuwe feature, bugfix of experiment leeft op zijn eigen branch:

• De hoofdbranch blijft intact; productie kan er op elk moment vanaf gedeployd worden.
• Twee mensen die parallel werken, zien elkaars half geschreven code nooit.
• Als een feature wordt geannuleerd, volstaat het verwijderen van de branch; er blijft geen spoor op main.
• Elke branch is een op zichzelf staande set wijzigingen die onafhankelijk te reviewen is.

Een branch aanmaken en benoemen

Werk vóór je begint de hoofdbranch bij, en maak er dan een nieuwe branch vanaf. In modern Git is dat één commando:

git switch main
git pull --ff-only
git switch -c feature/gebruiker-login

git switch -c maakt de branch en stapt erop over; het oudere git checkout -b doet hetzelfde. Een consistente prefix in branchnamen toont meteen het type werk wanneer je de lijst doorloopt:

• feature/ — een nieuwe feature
• fix/ — een bugfix
• chore/ — dependencies, configuratie, opschoning
• refactor/ — interne herstructurering die het gedrag niet verandert

Houd de naam kort maar betekenisvol: fix/login-csrf, feature/payment-webhook. Is er een issuenummer, voeg het toe: feature/142-pdf-export.

Commit-discipline

Een commit moet één logische wijziging beschrijven. "Alles in één commit" en "een aparte commit voor elke regel" zijn de twee uitersten die je vermijdt. Een goede boodschap beantwoordt het waarom in plaats van het wat, want het "wat" is al zichtbaar in de diff:

git add app/Http/Controllers/AuthController.php
git commit -m "fix: doorsturen naar login in plaats van 419 bij verlopen sessie"

Het Conventional Commits-formaat (feat:, fix:, chore:, docs:) is zowel leesbaar als handig om automatisch een changelog te genereren. Houd de eerste regel op 50–72 tekens en voeg indien nodig na een lege regel detail toe. Vermijd het committen van onafgemaakte code die niet compileert; heb je echt een tussentijdse opslag nodig, gebruik dan git stash of een gemarkeerde "WIP"-commit en ruim die later op met git rebase.

De branch actueel houden: merge of rebase?

Terwijl jij op je branch werkt, schuift de hoofdbranch op. Er zijn twee manieren om je branch bij te werken. Merge integreert de wijzigingen van main in je branch en laat een merge-commit achter; de geschiedenis is eerlijk maar oogt vertakt. Rebase speelt je commits opnieuw af alsof ze bovenop de nieuwste main waren begonnen; de geschiedenis blijft vlak en leesbaar.

git switch feature/gebruiker-login
git fetch origin
git rebase origin/main

De praktische regel: rebase gerust om de geschiedenis op te schonen van een lokale branch die je nog niet hebt gedeeld. Maar rebase geen branch die anderen al hebben gepulld om die vervolgens geforceerd te pushen (--force) — dat corrumpeert de geschiedenis van je medewerkers. In dat geval is --force-with-lease veiliger, want het weigert te pushen als er iets is gewijzigd sinds de stand die jij het laatst zag.

De pull request: je wijziging zichtbaar gemaakt

Is de branch klaar, push hem dan naar de remote en open een pull request (PR):

git push -u origin feature/gebruiker-login

De PR is waar de code wordt besproken vóór de merge. Een goede PR is klein — wijzigingen onder de 400 regels worden aanzienlijk beter gereviewd, omdat de reviewer het geheel in zijn hoofd kan houden. De beschrijving zou moeten bevatten:

• Wat er veranderde en waarom: één zin context volstaat meestal.
• Hoe het getest is: een screenshot, commando-uitvoer of teststappen.
• Een link naar het bijbehorende issue (bijv. Closes #142).

Geautomatiseerde controles (CI) — tests, linter, build — zouden op de PR moeten draaien. Merge niet voordat het groen is. Dat elimineert grotendeels het "het werkte op mijn machine"-probleem.

Code review en mergen

Review is geen hek; het is gedeeld eigenaarschap. De reviewer jaagt niet alleen op bugs — hij vraagt naar naamgeving, randgevallen en of een eenvoudiger oplossing mogelijk is. Commentaar richt zich op het probleem, niet op de persoon; "wat gebeurt er in dit geval?" houdt de samenwerking gezonder dan "waarom heb je het zo gedaan?".

Eenmaal goedgekeurd, kies je een merge-strategie:

• Squash merge: bundelt alle commits van de branch tot één schone commit. De hoofdgeschiedenis blijft leesbaar; dit is de standaard voor de meeste teams.
• Merge commit: behoudt de volledige geschiedenis van de branch. Goed voor grote, betekenisvolle commitreeksen.
• Rebase merge: voegt de commits in vlakke vorm aan main toe, zonder merge-commit.

Verwijder na de merge de branch — zowel remote als lokaal. Opgestapelde dode branches maken het lastiger om de echte staat van de repository te lezen.

git switch main
git pull --ff-only
git branch -d feature/gebruiker-login
git push origin --delete feature/gebruiker-login

Veelgestelde vragen

Is rechtstreeks naar main pushen nooit oké?

Op een klein soloproject is het prima. Maar zodra er meer dan één persoon bij betrokken is, maak je de hoofdbranch protected en stuur je elke wijziging via een PR. Dat dwingt zowel review als het CI-vangnet af.

Moet ik merge of rebase gebruiken?

Beide zijn juist; het is een teamkeuze. Een praktische balans: rebase om je lokale branch actueel te houden en commits op te ruimen, en squash merge om de PR in main te brengen. Force-rebase nooit een gedeelde branch.

Hoe groot moet een PR zijn?

Zo klein mogelijk. Laat hem één logische taak omvatten. Is een feature groot, splits hem dan op in kleine PR's die onafhankelijk kunnen mergen; reviewen en terugdraaien worden zo eenvoudiger.

Lukt het niet om de git-flow van je team op orde te krijgen? Heb je hulp nodig met branchstrategie, CI-opzet en een code-reviewcultuur, neem dan contact op — laten we samen een eenvoudige workflow bouwen die bij je project past.