Trunk-Based Development

All changes integrate into a single shared trunk with no intermediate branches.

  3 minute read  

“Trunk-based development has been shown to be a predictor of high performance in software development and delivery. It is characterized by fewer than three active branches in a code repository; branches and forks having very short lifetimes (e.g., less than a day) before being merged; and application teams rarely or never having ‘code lock’ periods when no one can check in code or do pull requests due to merging conflicts, code freezes, or stabilization phases.”

  • Accelerate by Nicole Forsgren Ph.D., Jez Humble & Gene Kim

Definition

Trunk-based development (TBD) is a team workflow where you integrate changes into the trunk with no intermediate integration (develop, test, etc.) branch. The two common workflows are making changes directly to the trunk or using very short-lived branches. Short-lived branches start from the trunk and integrate back into the trunk.

Some teams choose release branches as an intermediate step on their path to continuous delivery while they improve the quality processes in their pipeline. True CD releases from the trunk.

Minimum activities required

  • All changes integrate into the trunk
  • If branches from the trunk are used:
    • They originate from the trunk
    • They re-integrate to the trunk
    • They are short-lived and removed after the merge

What is improved

  • Smaller changes: TBD emphasizes small, frequent changes that are easier for the team to review and more resistant to impactful merge conflicts. Conflicts become rare and trivial.
  • We must test: TBD requires you to write tests as part of the development process.
  • Better teamwork: You need to work more closely as a team. Closer teamwork has many positive impacts, not least a stronger focus on getting the team’s highest priority done.
  • Better work definition: Small changes require you to decompose the work into fine detail. That detail uncovers things that lack clarity or do not make sense, which gives much earlier feedback on potential quality issues.
  • Replaces process with engineering: Instead of a process that controls the release of features with branches, you control feature release with engineering techniques. These techniques are called evolutionary coding methods. They also improve stability in ways that a branching process cannot.
  • Reduces risk: Long-lived branches carry two common risks. First, the change will not integrate cleanly and the merge conflicts result in broken or lost features. Second, the branch will be abandoned, usually because of the first reason.

Migration guidance

For detailed guidance on adopting TBD during your CD migration, see:

Additional resources

Last modified October 8, 2026: docs(style): rewrite reference for sentence length, voice, and precision (da7097e)