Regels zijn er om te breken: hoe Nederlandse dev-teams hun eigen Git-universum bouwen

Als je aan een willekeurige Nederlandse developer vraagt hoe hun Git-workflow eruitziet, krijg je zelden een antwoord dat rechtstreeks uit een textbook komt. Geen keurig GitFlow-diagram, geen perfecte trunk-based setup. Wat je wél krijgt: een verhaal vol uitzonderingen, tijdelijke oplossingen die permanent werden, en branch-naamgevingsconventies die ooit logisch klonken maar nu niemand meer begrijpt.

En dat is misschien wel precies de reden waarom het werkt.

De mythe van de perfecte workflow

De techwereld heeft een lichte obsessie met 'best practices'. GitFlow, GitHub Flow, trunk-based development — ze worden gepresenteerd als universele waarheden. Maar wie ooit in een echt team heeft gewerkt, weet dat geen enkel project netjes in zo'n sjabloon past.

Neem Bram, lead developer bij een Amsterdams SaaS-bedrijf dat liever anoniem blijft. Zijn team begon drie jaar geleden met een strikte GitFlow-implementatie. Feature branches, release branches, hotfix branches — het hele circus. "Binnen twee maanden hadden we zo'n ingewikkeld branch-woud dat niemand meer wist welke versie nou eigenlijk live stond," vertelt hij. "We hebben het systeem vereenvoudigd tot iets wat wij zelf bedacht hebben. Geen naam voor, gewoon: het werkt voor ons."

Dat 'gewoon iets wat werkt' is in Nederland vaker de norm dan de uitzondering.

Hollands pragmatisme als ontwerpprincipe

Er zit iets typisch Nederlands in de manier waarop veel teams omgaan met technische conventies. Geen overdreven respect voor autoriteit of traditie — als iets niet werkt, gooi je het weg en bouw je iets nieuws. Dat pragmatisme, soms ook wel nuchterheid genoemd, sijpelt door in hoe teams hun versiebeheersystemen inrichten.

Een team in Rotterdam dat werkt aan open-source tooling voor de logistieke sector beschreef hun aanpak als 'feature flags met branches als vangnet'. Ze gebruiken nauwelijks release branches, werken bijna altijd direct op main, maar hebben een uitgebreid systeem van feature toggles gebouwd zodat onafgemaakte code veilig gedeployd kan worden. Officieel heet dat trunk-based development met feature flags — maar zij noemen het gewoon 'hoe wij het doen'.

Wanneer improvisatie productief is

Zelfbedachte workflows hebben een slechte reputatie, maar die is niet altijd verdiend. Er zijn concrete situaties waarin afwijken van de standaard juist slimmer is:

Klein team, hoog tempo. Een startup met vier developers heeft weinig baat bij de overhead van een formeel release-proces. Een simpele main-plus-feature-branches-aanpak met goede commit messages doet het werk prima. De energie die je bespaart op ceremony, steek je in daadwerkelijke features.

Specifieke deploymentomgevingen. Wie software levert aan overheidsinstanties of grote corporates in Nederland weet: de acceptatieomgeving is heilig. Sommige teams bouwen een speciale 'ota-branch' (van: over-te-accepteren) die alleen bestaat om code te parkeren voor externe reviews. Staat nergens in een handleiding, maar lost een reëel probleem op.

Open-source projecten met externe contributors. Hier zie je soms het omgekeerde: teams die bewust kiezen voor een bekende standaard (zoals GitHub Flow) juist omdat externe contributors dan meteen begrijpen hoe ze kunnen bijdragen. De workflow is dan niet optimaal voor het kernteam, maar verlaagt de drempel voor de community.

Wanneer het misgaat

Zo eerlijk moeten we ook zijn: zelfbedachte Git-workflows kunnen spectaculair de mist in gaan. En dan niet op de kleine, gezellige manier.

Het grootste risico is kennisconcentratie. Als de workflow alleen in het hoofd van één persoon zit — degene die hem bedacht heeft — dan is een ziektemelding of vertrek van die persoon een ramp. Codebases met cryptische branch-namen als feature-jan-v3-definitief-2 of hotfix-voor-die-bug-van-vrijdag zijn geen fictie. Ze bestaan, en ze zijn het digitale equivalent van een la vol ongecategoriseerde bonnetjes.

Een tweede valkuil: schaalbaarheid. Wat werkt voor een team van drie mensen, werkt zelden voor een team van twaalf. Teams die groeien zonder hun workflow aan te passen, lopen vroeg of laat tegen conflicten aan — niet alleen in code, maar ook in samenwerking en verantwoordelijkheden.

De gouden middenweg: documenteer je eigenzinnigheid

Het verschil tussen een productieve afwijking en een chaotische puinhoop zit hem zelden in de workflow zelf, maar in de documentatie ervan. Een zelfbedachte aanpak die nergens is vastgelegd, is een tijdbom. Dezelfde aanpak, helder opgeschreven in een CONTRIBUTING.md of een intern wiki-pagina, is een krachtig stuk teamidentiteit.

Praktisch betekent dat:

• Leg de redenering vast, niet alleen de regels. Waarom gebruik je geen release branches? Schrijf het op. Dan kan een nieuwe collega de afweging begrijpen in plaats van alleen de conclusie.
• Maak uitzonderingen expliciet. Als er situaties zijn waarin je van de standaardaanpak afwijkt (bijvoorbeeld bij hotfixes of externe releases), beschrijf die dan apart.
• Herzie regelmatig. Een workflow die zes maanden geleden logisch was, hoeft dat nu niet meer te zijn. Plan een kwartaalsessie om samen te kijken of de aanpak nog past bij de huidige situatie van het team.

Leren van de kapers

De naam PiratePad is niet voor niets. Er zit een bepaalde energie in het idee van buiten de geijkte paden opereren — niet uit onwetendheid, maar uit een bewuste keuze om te doen wat werkt. De beste piraten kenden de regels van de zee beter dan wie dan ook. Ze kozen er gewoon voor ze anders toe te passen.

Datzelfde geldt voor Git-workflows. De teams die het meest succesvol hun eigen weg gaan, zijn zelden de teams die de standaarden niet kennen. Het zijn juist de teams die GitFlow hebben geprobeerd, trunk-based development hebben geëxperimenteerd, en op basis van die ervaring iets eigens hebben gebouwd.

Dat is geen rebels gedrag om het rebels zijn. Dat is gewoon goed vakmanschap.

Conclusie: chaos of karakter?

Nederlandse dev-teams die hun eigen Git-conventies bouwen, doen iets wat op het eerste gezicht rommelig lijkt maar bij nader inzien best verdedigbaar is. Zolang de keuzes bewust zijn, de aanpak gedocumenteerd is en het team als geheel de workflow begrijpt, is afwijken van de standaard geen probleem — het is een keuze.

De echte vraag is niet: 'Gebruik je de juiste workflow?' De vraag is: 'Werkt jouw workflow voor jouw team, en weet iedereen waarom?'

Als je die vraag met ja kunt beantwoorden, mag je gerust je eigen Git-universum blijven bewonen. Geef het alleen wel een naam, zodat de rest van de crew ook weet waar ze zijn.