Trunk-Based Development
Also known as: TBD, trunk based development
Trunk-based development is the practice of integrating every change into a single shared branch at least daily, with short-lived branches measured in hours. It keeps merge conflicts small and continuous integration honest, and it depends on feature flags to keep unfinished work from being visible.
Last reviewed · Part of the Architecture Glossary
In practice
The economics are about conflict probability, which grows with both branch age and the number of concurrent branches. A branch open for three weeks against an active codebase is not a branch — it is a fork with a merge deadline, and the merge is a distinct piece of unestimated work.
What has to be true for it to work:
- Feature flags, so incomplete work can be merged without being reachable.
- A fast pipeline. If CI takes 40 minutes, nobody integrates daily. Under 10 minutes to a merge decision is the practical bar.
- Expand-migrate-contract for schemas, so main is always deployable against the current database.
- Small changes. A 2,000-line pull request cannot be reviewed daily, so it will not be merged daily.
The DORA research consistently associates it with higher deployment frequency and lower change-failure rate — the two metrics that usually get treated as a trade-off.
When it matters
Any team above three engineers on one codebase, and any team whose deploy frequency they want to raise without lowering stability.
Common mistake
Adopting the branching policy without the flags or the pipeline speed. Then main is broken, everybody blames trunk-based development, and the team returns to long-lived branches with the conflict cost intact.
See also
- Feature FlagA feature flag is a runtime switch that changes behaviour without a deploy, separating release from deployment.
- Canary ReleaseA canary release routes a small fraction of production traffic to a new version, compares its error and latency metrics against the stable version, and promotes or rolls back based on the result.
- Contract TestingContract testing verifies that a provider's API satisfies the expectations its consumers actually rely on, by running each consumer's recorded expectations against the provider in isolation.