Trunk-based development
Also known as: trunk-based workflow, mainline development
Trunk-based development is a way of working where every developer merges small changes into a single main branch, the 'trunk,' frequently, usually at least once a day.
Unfinished work is hidden behind feature flags instead of living on long-running branches. While it can feel risky to share half-finished code, research consistently links it with faster, more stable delivery, because small merges are much easier to review and fix than giant ones.
Trunk-based development, explained at three levels
At home
Imagine a group writing one shared document. If everyone edits separate copies for weeks, combining them is a nightmare. If everyone adds small edits to the shared copy every day, it stays consistent. Trunk-based development is the second approach for code.
At work
With trunk-based development, teams avoid 'merge hell,' the painful days spent combining big branches. Small, frequent changes are reviewed faster, tested continuously, and easier to undo.
At home
Developers may still use short-lived branches for code review, but those branches last hours or a day or two, not weeks. Automated tests run on every merge to make sure the trunk always works.
At work
Trunk-based development depends on strong CI, fast automated tests, code review that keeps up, and feature flags to hide incomplete work. Releases can be cut from the trunk at any time, sometimes using short release branches that only receive fixes.
At home
Long branches drift further from the trunk each day, so the cost of merging grows faster than the branch's age. In my opinion, that's the core argument: merge pain isn't linear, so you pay less overall by merging small and often.
At work
Moving from Git flow requires investment: test suites fast enough to run on every commit, techniques such as branch by abstraction for large refactors, and cultural comfort with incomplete code in production behind flags. Regulated teams can still meet approval requirements through pull-request reviews and automated evidence rather than long release branches.
Real-world examples
At home
Lena contributes to an open-source project that asks for small pull requests merged within a day. At first it felt slower, but her changes stopped colliding with other people's work, and she spent far less time fixing merge conflicts.
At work
Marcus is a team lead at a Halifax software company whose releases kept slipping because of week-long merge fights. After moving to trunk-based development with feature flags, the team shipped every day and merge conflicts became a rare annoyance.
How it compares
| feature | Trunk-based development | Git flow |
|---|---|---|
| Branch lifespan | Hours to a day or two | Weeks or longer |
| Merge pain | Small and frequent | Large and occasional |
| Unfinished work | Hidden behind flags | Kept on feature branches |
| Best fit | Continuous delivery of web services | Versioned software with scheduled releases |
Trunk-based development trades isolation for continuous integration.
For analysts
If releases are often delayed by 'integration,' long-lived branches are a likely cause. I'd look at average branch age as a simple health metric before buying new tooling.
History & origin
Early version control systems such as CVS and Subversion encouraged working on a shared trunk because branching was painful. Git made branching cheap after 2005, and Vincent Driessen's 2010 'Git flow' model, with long-lived develop and release branches, became hugely popular. Continuous delivery advocates pushed back, and Paul Hammant's site documenting trunk-based development gave the practice a reference. The 2018 book Accelerate, based on DORA research, found trunk-based development among the practices that predicted high performance. In 2020, Driessen himself added a note saying simpler workflows suit teams doing continuous delivery. In my view, that note is one of the more honest updates in software history.