Trunk-Based Development

The whole team integrates into a single branch (trunk/main) using very short-lived branches and feature flags.

Context

Teams with continuous integration and delivery that want to minimize the cost of integrating. It is the model most associated with high-performing teams in DORA metrics (deploy frequency and lead time).

Problem

Long-lived branches diverge. The later they are integrated, the more conflicts, risk and "hidden" work nobody sees until the end.

Solution
  • There is one integration branch: main (the trunk).
  • Everyone commits directly to the trunk or uses short-lived branches (less than a day or two).
  • The trunk always builds and passes tests: CI runs on every push.
  • Unfinished work hides behind Feature Flags, not in a branch.
  • Big changes use branch by abstraction: introduce an abstraction, migrate gradually, retire the old implementation.

#Flow

CSHARP 
main ──●──●──●──●──●──●──●──●──▶   (always deployable)
        \  /    \  /
         ●       ●     ← branches of hours, not weeks
BASH 
git switch -c fix/rounding-error
# ... small change, local tests
git push -u origin fix/rounding-error
# short PR, fast review, merge today
git switch main && git pull --ff-only

#Releases

  • From the trunk: every green commit is a production candidate (continuous deployment).
  • Short release branch: if you need to stabilize, cut release/1.4 from the trunk; fixes land on the trunk first and are cherry-picked into the release branch.

#What you need for it to work

  • Fast CI (minutes, not hours) and reliable automated tests.
  • Feature flags and a way to clean them up when no longer used.
  • Fast code reviews (small PRs) or pair/mob programming.
  • A culture where "a broken build is the top priority".
When NOT to use it
  • No automated tests or reliable CI: you will break main often.
  • Teams with many newcomers and no fast review process.
  • Software with several versions supported in parallel: prefer release branches (see GitFlow).
Tradeoffs
Pro Con
Trivial merges, almost no conflicts Demands solid CI and tests
Very frequent feedback and deploys Requires discipline with feature flags
Less branch-management overhead Cultural: hard for teams coming from long branches

#git #branching #ci #trunk-based