📖 Business
Trunk-Based Development
Trunk-based development is a version control strategy where all developers commit to a single shared branch (trunk/main) at least once per day. There are no long-lived feature branches. Any branch that lasts more than a day is considered an anti-pattern — it defers integration pain and accumulates merge debt that grows exponentially with time. This is not recklessness; it is a discipline. It requires specific techniques (feature flags, branch by abstraction, small commits) to keep the trunk always shippable while allowing incomplete work to coexist with released features. Research from the Accelerate/DORA studies confirms that trunk-based development is one of the strongest predictors of high software delivery performance.
2
Minutes
2
Concepts
+45
XP
1
How It Works
How to work without long-lived feature branches:
1. Feature Flags
- Commit unfinished features behind conditional flags
- The code is in production but invisible to users
- Toggle flags to enable features when ready
- Clean up flags after full rollout
2. Branch by Abstraction
- When replacing a large component (e.g., swapping a payment provider):
- Create an abstraction layer in front of the existing component
- Build the new implementation behind the abstraction
- Gradually shift traffic from old to new
- Remove the old implementation when the new one is proven
- All committed to trunk incrementally — no massive merge at the end
3. Small Commits
- Break work into the smallest possible increments that keep trunk shippable
- A feature that takes two weeks becomes 20+ commits, each safe to deploy
- "If your commit message needs the word 'and,' your commit is too big"
Why long-lived branches fail:
- Merge conflicts grow nonlinearly with branch lifetime
- Integration bugs hide until the merge — discovered late, expensive to fix
- Developers work in isolation, making conflicting design decisions
- Code review becomes impossible when the diff is 5,000 lines
- CI only tests the branch, not the integrated whole
What trunk-based development enables:
- Continuous integration is real (you're actually integrating continuously)
- Every commit is tested against the integrated codebase
- Merge conflicts are tiny and immediate
- Code review is fast (small diffs, reviewed daily)