Branching zonder bloedvergieten: zo werkt je dev-team als een goed ingevaren crew

Elk development team kent ze: die vrijdagmiddag waarop iemand per ongeluk de verkeerde branch merget, de main omgooit en het hele weekend verpest. Of die eeuwige CONFLICT (content): Merge conflict in src/app.js die je elke keer weer doet verzuchten. Git is een geweldig gereedschap — maar zonder een goede workflow is het alsof je een schip bestuurt zonder roer.

Op PiratePad geloven we dat samenwerken aan code net zo soepel kan verlopen als het schrijven ervan. Daarom duiken we vandaag in de wereld van Git workflows: wat zijn je opties, wanneer kies je waarvoor, en hoe implementeer je dat zonder je codebase in een puinhoop te veranderen?

Waarom een workflow überhaupt nodig is

Als je solo codeert, kom je een heel eind met gewoon pushen naar main. Maar zodra je met twee of meer mensen aan hetzelfde project werkt, verandert de dynamiek compleet. Iedereen heeft zijn eigen tempo, zijn eigen feature, zijn eigen manier van denken. Zonder afspraken loopt dat vroeg of laat vast.

Een Git workflow is in essentie een set spelregels: wie mag wat pushen, wanneer, en via welk pad. Het gaat niet om bureaucratie — het gaat om vrijheid. Als iedereen weet hoe het spel gespeeld wordt, kan iedereen ongestoord zijn eigen deel bouwen.

GitFlow: de klassieke aanpak voor grotere projecten

GitFlow is de veteraan onder de workflows. Ontwikkeld door Vincent Driessen in 2010, is het inmiddels een begrip in de industrie. De kern: je hebt twee permanente branches (main en develop), aangevuld met tijdelijke branches voor features, releases en hotfixes.

Hoe het werkt:

• Nieuwe features krijgen hun eigen feature/naam-branch, vertakkend van develop
• Als een feature klaar is, wordt hij gemerged terug naar develop
• Wanneer je klaar bent voor een release, maak je een release/x.x-branch
• Na go-live merge je die naar zowel main als develop
• Spoedoplossingen gaan via een hotfix-branch direct naar main

Wanneer kies je hiervoor? GitFlow schittert bij projecten met vaste release-cycli en meerdere versies in productie — denk aan software met enterprise-klanten of apps die je niet continu kunt deployen. Voor een Nederlands SaaS-bedrijf met kwartaalreleases is dit een solide keuze.

Het nadeel: de overhead is fors. Voor kleine teams of projecten die snel willen itereren, voelt GitFlow al snel als een pak bureaucratie.

Trunk-based development: snel, licht en brutaal eerlijk

Aan de andere kant van het spectrum staat trunk-based development (TBD). Hier is het idee simpel: iedereen werkt zo dicht mogelijk bij de main-branch (de 'trunk'). Features worden klein gehouden, branches leven maar kort — maximaal een dag of twee — en er wordt meerdere keren per dag gemerged.

De kracht van TBD zit in de eerlijkheid. Als je code niet integreert, weet je dat meteen. Geen grote verrassingen bij een release; alles wordt continu getest en gevalideerd.

Praktisch voorbeeld: stel je bouwt een nieuwe zoekfunctie. In plaats van weken aan een feature/search-branch te werken, breek je de feature op in kleine stukken: eerst de UI-component, dan de API-koppeling, dan de filters. Elk stuk is op zichzelf werkend (of afgeschermd met een feature flag) en wordt snel gemerged.

Wanneer kies je hiervoor? Als je team werkt met continuous deployment, een sterke testcultuur heeft en snel wil bewegen. Veel Nederlandse scale-ups en techbedrijven die agile werken, zetten inmiddels in op TBD.

Forking workflow: de open-source standaard

Ken je GitHub? Dan ken je de forking workflow, want het is de ruggengraat van bijna elk open-source project. In plaats van dat iedereen direct op hetzelfde repository werkt, forkt elke contributor zijn eigen kopie. Wijzigingen gaan via pull requests terug naar het origineel.

Dit model is fantastisch voor situaties waar je niet iedereen directe schrijftoegang wilt geven — of kunt geven. Denk aan community-projecten, of intern aan een situatie waar junior developers hun werk altijd via review willen laten gaan.

De valkuil: forks kunnen snel uit de pas lopen met het origineel. Regelmatig synchen is geen optie, het is een verplichting.

Hoe kies je de juiste workflow voor jouw team?

Er bestaat geen universeel juist antwoord. Maar er zijn wel een paar vragen die je helpen:

1. Hoe groot is je team? Klein team (2-4 personen) = minder structuur nodig. Groot team = meer afspraken essentieel.
2. Hoe vaak deploy je? Meerdere keren per dag? Trunk-based. Eens per maand? GitFlow.
3. Hoe volwassen is je testinfrastructuur? TBD zonder goede CI/CD is vragen om problemen.
4. Zijn er externe contributors? Dan is de forking workflow bijna altijd de beste keuze.

Praktische tips om vandaag mee te starten

Ongeacht welke workflow je kiest, zijn er een paar universele gewoontes die je team meteen verder helpen:

Houd branches klein en gefocust. Eén branch, één doel. Geen 'branch-met-alles-erop'.

Schrijf beschrijvende commit messages. fix bug is nutteloos. fix: correct null check in user authentication flow is goud waard voor je toekomstige zelf.

Gebruik pull request templates. Geef reviewers context: wat heb je gebouwd, hoe test je het, zijn er afhankelijkheden? Een simpel .github/pull_request_template.md doet wonderen.

Automatiseer je checks. Linters, tests, security scans — laat ze automatisch draaien bij elke PR. Zo voorkom je dat mensen handmatig de politieagent moeten spelen.

Praat erover. De beste workflow is de workflow waar je team achter staat. Bespreek regelmatig wat werkt en wat niet. Een retrospective over je Git-gewoontes klinkt misschien saai, maar voorkomt een hoop frustratie.

De workflow is het fundament, de cultuur is het huis

Uiteindelijk is een Git workflow niet meer dan een gereedschap. Het lost geen communicatieproblemen op, het vervangt geen goede code reviews en het maakt slechte tests niet beter. Maar het geeft je team een gemeenschappelijke taal en een gedeeld ritme.

Een goed functionerend dev-team is als een goed ingevaren scheepscrew: iedereen kent zijn rol, weet wanneer hij aan de beurt is en vertrouwt erop dat de anderen hun deel doen. De workflow is het navigatiesysteem. De cultuur is wat het schip daadwerkelijk laat varen.

Dus: kies je workflow bewust, pas hem aan als het niet werkt, en zorg dat iedereen aan boord is. Dan vaart het vanzelf een stuk soepeler.