# Wat is trunk based development: de volledige uitleg

URL: https://formula.dog/nl/journal/wat-is-trunk-based-development
Type: blog
Locale: nl
Published: 2026-09-12
Updated: 2026-09-13

---

> Trunk based development: alle ontwikkelaars committen dagelijks naar de gedeelde trunk. Geen lange branches, wel feature flags en CI bij elke commit.

Wat is trunk based development? Elke ontwikkelaar in het team commit dagelijks code naar een gedeelde branch -- de trunk, meestal "main" geheten. Geen langlopende feature branches. Geen hotfix-v2-backup-final die weken blijft rondhangen. Korte branches leven slechts uren, worden snel gemerged en vervolgens verwijderd. De codebase is altijd klaar om te releasen. [Google werkt zo met 35.000 ontwikkelaars](https://trunkbaseddevelopment.com/). Hier is hoe het werkt, wanneer het zinvol is, en wanneer niet.

## Het "rapport_v2_DEFINITIEF_gebruik_dit.xlsx" probleem -- maar dan voor code

Ken je dat? Je opent een gedeelde map en vindt `rapport_v1.xlsx`, `rapport_v2_DEFINITIEF.xlsx` en `rapport_GEBRUIK_DIT_greg_wijzigingen.xlsx` naast elkaar. Dan begrijp je precies welk probleem trunk based development wil oplossen.

Datzelfde gebeurt in codebases wanneer teams langlopende feature branches gebruiken. Iemand begint aan een feature in week een. De rest van het team blijft doorontwikkelen. Tegen week drie staat die branch tientallen commits achter op main. Mergen wordt een weekendproject waar niemand verantwoordelijkheid voor wil nemen. Conflicts stapelen zich op. De ontwikkelaar die de code schreef is al lang vergeten waarom de helft ervan bestaat. Dit is "merge hell."

Gitflow -- het meest gedoceerde alternatief -- probeert dit op te lossen met formele structuur: aparte branches voor features, releases en hotfixes, elk met een gedefinieerde levensduur. De structuur ziet er netjes uit op papier. In de praktijk hopen branches zich op als spreadsheetversies op een gedeeld netwerkstation, en "integration day" wordt "integration week."

Trunk based development neemt het tegenovergestelde standpunt in: stop met het opbouwen van integratieachterstand. Commit naar main. Vandaag.

## Iedereen commit naar main. Elke dag. Dat is het hele model.

De basisregel is eenvoudig: alle ontwikkelaars pushen wijzigingen naar de gedeelde trunk minstens eenmaal per 24 uur. Geen uitzonderingen voor "ik ben nog niet klaar" -- je commit wat je hebt, en je zorgt dat wat je hebt de build niet breekt.

Dit klinkt alarmerend totdat je begrijpt welke mechanismen het veilig maken:

- 
**Kortlopende branches**: Je kunt nog steeds branches gebruiken, maar die leven uren, niet weken. Een branch die langer dan twee dagen bestaat is een waarschuwingssignaal dat aandacht verdient.

- 
**Geautomatiseerd testen bij elke commit**: Je CI-pipeline draait de testsuite direct. Als iets breekt, weet je dat binnen minuten, niet aan het einde van een sprint.

- 
**Feature flags**: Half gebouwde features blijven verborgen achter een toggle totdat ze klaar zijn om te shippen. Gebruikers zien nooit onafgerond werk, ook al staat het al in de productiecode.

Het resultaat is een codebase die altijd releasable is -- niet "releasable nadat we de feature branch mergen en een week QA draaien", maar releasable nu als dat nodig is. Dat is de fundamentele belofte.

![Multiple code commits converging into one main branch in trunk-based development](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-09/f48347-inline1.webp)

## Kortlopende branches: meet ze in uren, niet in weken

In trunk based development ben je niet verbannen van branches. Je bent verbannen van lange branches.

Een branch die je om 9 uur opent, waar je de ochtend aan werkt, na de lunch een code review op krijgt en voor 17 uur naar main merget -- dat is precies het goede type. Het geeft je teamleden de kans om het werk te reviewen voordat het op de trunk terechtkomt. Het is klein genoeg om in een keer te begrijpen. Conflicts, als die er zijn, los je op in minuten.

Een branch die drie weken leeft terwijl een ontwikkelaar een volledig authenticatiesysteem in isolatie bouwt, is het probleem. Wanneer de tijd eindelijk komt om te mergen, besteedt het team meer tijd aan het oplossen van conflicts dan aan het bouwen van de feature.

De praktische drempel die de meeste trunk based teams hanteren: als een branch niet binnen twee dagen is gemerged, moet er iets veranderen. De feature is te groot en moet worden opgedeeld in kleinere stukken, of er is een feature flag nodig zodat gedeeltelijk werk veilig kan landen.

Werk opdelen in kleinere stukken is de kernvaardigheid die trunk based development daadwerkelijk traint. In plaats van "bouw het hele dashboard", ship je eerst "voeg de datalaag toe", dan "voeg het eerste chart toe", dan "koppel de filters." Elk stuk mergt naar de trunk, wordt getest en shipt onafhankelijk. De volledige feature verschijnt incrementeel over meerdere commits.

Dit klinkt langzamer. In de praktijk is het sneller, omdat je problemen ontdekt terwijl de context nog vers is en het oppervlak nog klein is.

## Feature flags: hoe je onafgerond werk shipt zonder iets te breken

Feature flags -- ook wel feature toggles genoemd -- zijn het mechanisme dat trunk based development praktisch maakt wanneer een feature niet in een enkele kortlopende branch kan worden afgerond.

Het idee is eenvoudig: wikkel nieuwe functionaliteit in een conditional die alleen activeert wanneer een specifieke vlag aan staat.

`if (featureFlags.nieuwRapportageDashboard) {
  toonNieuwDashboard();
} else {
  toonOudDashboard();
}`De nieuwe code wordt naar productie gedeployed. Maar die draait niet voor gebruikers totdat je de toggle omzet. Dit betekent:

- 
Ontwikkelaars kunnen work-in-progress naar de trunk committen zonder iemand te beïnvloeden

- 
QA kan de feature in productie testen door de vlag aan te zetten voor een specifieke gebruiker of omgeving

- 
Een lancering wordt een configuratiewijziging, geen deployment-event

- 
Als iets breekt, zet je de vlag uit -- geen rollback of hotfix branch nodig

Feature flag infrastructuur varieert van een eenvoudige omgevingsvariabele die bij het opstarten wordt gecontroleerd, tot dedicated feature flag platforms. Voor een team dat net begint, is een config-bestand of een variabele per omgeving voldoende. Het gaat om de mogelijkheid, niet om de complexiteit van de tooling.

![Feature flag toggle switches controlling code deployment in trunk-based development](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-09/d557e7-inline2.webp)

## Wanneer trunk based development niet de juiste keuze is

Het is de moeite waard om dit direct te zeggen: trunk based development is niet universeel beter. Het past bij specifieke contexten.

Sla het over als:

**Je CI/CD-pipeline nog niet klaar is.** Trunk based development zonder geautomatiseerde tests bij elke commit is geen branchingstrategie -- het is een kapotte codebase die snel groeit. De testinfrastructuur moet op zijn plaats zijn voordat het branchingmodel kan werken.

**Het team door de aard van het werk niet frequent kan committen.** Gedistribueerde teams waarbij bijdragers asynchroon werken in verschillende tijdzones, of open-source projecten waarbij bijdragers onregelmatig batches indienen, zullen moeite hebben met de dagelijkse commit-cadans.

**Je in een gereguleerde omgeving zit met verplichte release-vensters.** Sommige sectoren vereisen externe goedkeuring, lange QA-cycli en formele auditsporen per releasebranch. De gestructureerde releasebranches van Gitflow passen beter bij dat soort workflow.

**De teamdiscipline er nog niet is.** Trunk based development vereist dat elke commit naar main ofwel alle tests doorstaat, ofwel direct wordt hersteld. Als je team kapotte builds tolereert, wordt de gedeelde trunk het gedeelde probleem van iedereen.

Gitflow is een redelijke keuze voor teams met kwartaalmatige release-schema's, meerdere gelijktijdige features ontwikkeld door afzonderlijke squads, of compliancevereisten die branch-niveau isolatie vereisen. De vraag is eerlijke fit, niet welke aanpak in principe wint.

## Hoe je van Gitflow naar trunk based development migreert zonder een crisis

Als je team op Gitflow zit en trunk based development wil proberen, hoeft de migratie geen harde omschakeling te zijn.

Begin met het stoppen van het aanmaken van nieuwe langlopende branches. Features die na de beslissing worden gestart krijgen kortlopende branches. Features die al in uitvoering zijn op lange branches ronden af onder het oude model. De twee aanpakken bestaan tijdelijk naast elkaar.

Voordat je onafgerond werk naar de trunk commit, moet je feature flags hebben. Het opzetten van zelfs een eenvoudig feature flag systeem is de voorwaarde voor al het andere. Zonder dat betekent trunk based development in de praktijk: onafgeronde UI naar productiegebruikers shippen.

Stel vervolgens CI in op de main branch: geautomatiseerde tests draaien bij elke push, falende tests blokkeren de merge, en niemand merget zonder een geslaagde build. Dit is het niet-onderhandelbare deel.

Definieer ten slotte expliciet de twee-dagenregel: elke branch die ouder is dan twee dagen krijgt een gesprek over wat er mee moet. Splits de feature kleiner op, voeg een vlag toe, of ship wat al klaar is. Maak dit zichtbaar in je pull request proces.

De ongemakkelijke aanpassing die de meeste teams ondervinden: accepteren dat "gedeeltelijk compleet" iets is wat je mag committen, zolang het verborgen is achter een vlag en bestaande tests niet breekt.

## Wat de DORA-rapportdata zegt over leveringssnelheid

De DevOps Research and Assessment (DORA) rapporten zijn het dichtstbijzijnde wat softwareontwikkeling heeft aan grootschalig empirisch onderzoek naar teampraktijken. Het DORA-rapport van 2021 stelde vast dat elite teams 2,3 keer vaker trunk based development gebruiken dan lager presterende teams.

Elite performers in het DORA-framework deployen meerdere keren per dag, met doorlooptijden van commit tot productie gemeten in uren in plaats van weken. Trunk based development correleert consistent met die uitkomsten.

De belangrijke kanttekening: correlatie is geen causaliteit. High-performing teams nemen trunk based development aan omdat ze al hebben geïnvesteerd in de onderliggende discipline -- geautomatiseerd testen, solide CI/CD-infrastructuur, ontwikkelaars die kleine, gerichte wijzigingen schrijven. Die fundamenten komen eerst. Trunk based development is het branchingmodel dat bij die context past, niet datgene dat die context creëert.

Biscuit snapt dit snel: een goede retriever probeert niet drie ballen tegelijk te apporteren. Een commit, een review, een merge. Good boy.

![Continuous deployment pipeline visualization showing code flowing from commits to production](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-09/6305c9-inline3.webp)

## Is trunk based development de overstap waard?

Als je team elke sprint merkbaar tijd kwijt is aan merge conflicts, releases vertraagt omdat "de feature branch nog niet klaar is", of branches open heeft staan zo lang dat niemand meer weet waarvoor ze waren -- dan is trunk based development een serieuze evaluatie waard.

De dagelijkse commit-cadans is veeleisend. De feature flag infrastructuur vergt opzetten. De culturele verschuiving duurt een paar weken. Maar het resultaat -- een codebase die altijd releasable is, merge conflicts gemeten in regels in plaats van bestanden, en releases die routine zijn in plaats van crises -- is een zinvolle verbetering in hoe het team werkt.

Begin klein: een team, een sprint, CI draait bij elke push, feature flags staan klaar. Kijk wat er in vier weken verandert.

## FAQ

### Wat is het verschil tussen trunk based development en Gitflow?

Bij Gitflow werk je met langlopende branches voor features, releases en hotfixes, elk met een gedefinieerde levensduur. Bij trunk based development commit iedereen dagelijks naar een gedeelde branch (de trunk). TBD vermijdt merge hell maar vereist feature flags en geautomatiseerde tests. Gitflow past beter bij teams met kwartaalmatige releases en strikte compliancevereisten.

### Hoe lang mag een branch leven in trunk based development?

De vuistregel is maximaal twee dagen. Een branch die je 's ochtends opent, na de lunch een code review krijgt en 's middags naar main merget, is ideaal. Als een branch ouder wordt dan twee dagen, is het tijd om de feature op te splitsen in kleinere stukken of een feature flag toe te voegen zodat gedeeltelijk werk veilig kan landen.

### Wat zijn feature flags en waarom zijn ze nodig bij trunk based development?

Feature flags zijn conditionals in de code die nieuwe functionaliteit verbergen achter een toggle. Ze stellen je in staat om onafgerond werk naar de trunk te committen zonder dat gebruikers het zien. Een lancering wordt een configuratiewijziging in plaats van een deployment. Als er iets fout gaat, zet je de vlag uit in plaats van een rollback uit te voeren.

### Is trunk based development geschikt voor kleine teams?

Ja, kleinere teams profiteren er vaak het meest van. Met minder ontwikkelaars is de dagelijkse commit-cadans eenvoudiger te handhaven en zijn branches van nature al korter. De vereiste voor CI/CD en feature flags geldt ongeacht de teamgrootte -- die infrastructuur is de werkelijke voorwaarde, niet het aantal teamleden.

### Hoe verhoudt trunk based development zich tot continue integratie?

Continue integratie (CI) is het technische fundament waarop trunk based development rust. CI betekent dat de testsuite automatisch draait bij elke push naar de trunk. Zonder CI kun je niet veilig meerdere keren per dag committen. TBD is het branchingmodel, CI is de infrastructuur die het veilig maakt.

### Gebruikt Google trunk based development?

Ja. Google werkt met 35.000 ontwikkelaars in een enkele monorepo-trunk. Dit is een van de meest geciteerde voorbeelden van trunk based development op grote schaal. Het laat zien dat het model werkt bij extreme omvang, mits de tooling en discipline aanwezig zijn.

### Wat zegt het DORA-rapport over trunk based development?

Het DORA-rapport van 2021 stelde vast dat elite teams 2,3 keer vaker trunk based development gebruiken dan lager presterende teams. Die teams deployen meerdere keren per dag met doorlooptijden van commit tot productie gemeten in uren. Correlatie is geen causaliteit -- de prestaties komen voort uit de onderliggende discipline, niet alleen het branchingmodel.