One line summary

A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’ *, resist any pressure to create other long-lived development branches by employing documented techniques, avoid merge hell, do not break the build, and live happily ever after.


* ‘master’, in Git nomenclature

Trunk-Based Development is a key enabler of Continuous Integration and by extension Continuous Delivery. When individuals on a team are committing their changes to the trunk multiple times a day it becomes easy to satisfy the core requirement of Continuous Integration that all team members commit to trunk at least once every 24 hours. This ensures the codebase is always releasable on demand and helps to make Continuous Delivery a reality.


  • Depending on the team size, and the rate of commits, very short-lived feature/task branches are used for code-review and build checking (CI) to happen before commits land in the trunk for other developers to depend on. Such branches allow developers to engage in eager and continuous code review of contributions before they land in the trunk.

  • Depending on the intended release cadence, there may be release branches that are cut from the trunk on a just-in-time basis, are ‘hardened’ before a release (without that being a team activity), and those branches are deleted some time after release. Alternatively, there may also be no release branches if the team is releasing from Trunk, and choosing a roll forward strategy for bug fixes. Releasing from trunk is also for high throughput teams, too.

  • Teams should become adept with the related branch by abstraction technique for longer to achieve changes, and use feature flags in day to day development to allow for hedging on the order of releases (and other good things - see concurrent development of consecutive releases)

  • If you have more than a couple of developers on the project, you are going to need a hook up a build server to verify that their commits have not broken the build

  • Development teams can casually flex up or down in size (in the trunk) without affecting throughput or quality. Proof? Google do Trunk-Based Development and have 25000 developers and QA automators in that trunk.

  • People who practice the GitHub-flow branching model will feel that this is quite similar, but there is one small difference (click that link to see).

  • People who practice the Gitflow branching model will find this very different, as will many developers used to the popular ClearCase, Subversion, Perforce, StarTeam, VCS branching models of the past.

  • Many publications, including the best-selling ‘Continuous Delivery’ book promote Trunk Based Development - this is not even controversial anymore.


Trunk-Based Development is not a new branching model. The word ‘trunk’ is referent to the concept of a growing tree, where the fattest and longest span is the trunk, not the branches that radiate from it and are of more limited length.

It has been a lesser known branching model of choice since the mid-nineties and considered tactically since the eighties. The largest of development organizations, like Google (as mentioned) and Facebook practice it at scale.

Over 30 years different advances to source-control technologies and related tools/techniques have made Trunk-Based Development more (and occasionally less) influential.

This site

This site attempts to collect all the related facts, rationale and techniques for Trunk-Based Development together in one place, complete with twenty-four diagrams to help explain things. All without using TBD as an acronym even once twice.