By admin , 29 April 2026

The model

Trunk-based development (TBD) keeps a single long-lived branch - the trunk, usually main - and integrates everything frequently, ideally many times per day. Feature branches, if used at all, live for hours, not weeks. The DORA research consistently links TBD to high-performing engineering organisations.

Two flavours

  • Pure TBD - everyone commits straight to trunk. Pre-commit hooks and CI gates protect quality. Used at Google and Meta scale.
  • Short-lived branches - branches live a few hours, behind a PR, merged within a day. The pragmatic choice for most teams.

Why TBD works

  • Conflicts surface daily, not weekly. Each conflict is small.
  • Trunk is always releasable - releases become routine.
  • No "big bang" merges, no "merge week" before a release.
  • Continuous integration becomes literal, not aspirational.

The challenge: incomplete features

If everything is on trunk, how do you ship trunk while a feature is half-finished? Three techniques:

  • Feature flags - merge code dark, enable later.
  • Branch by abstraction - introduce an interface, swap implementations gradually.
  • Keystone interfaces - wire the new path last, after all components land.

A typical day

git checkout main
git pull --rebase
git checkout -b quick-fix
# ...work for two hours...
git rebase main
git push -u origin quick-fix
# open PR, get review, merge within hours
git checkout main
git pull --rebase
git branch -d quick-fix

Required guardrails

TBD demands strong CI:

  • Fast tests - under 10 minutes ideally.
  • Pre-merge checks block broken commits from trunk.
  • Automated rollback or feature flag kill switches.

Releases

Two patterns:

  • Release from trunk - tag whatever commit you ship. Continuous deployment.
  • Release branches - cut a short-lived release/x.y for stabilisation, cherry-pick fixes, never merge back. Trunk is unaffected.
git tag -a v1.4.0 -m "Release 1.4.0"
git push origin v1.4.0
# CI builds and deploys

Common objections

  • "We need feature branches for review." Use short-lived branches behind PRs - that is still TBD.
  • "Our tests are slow." Fix the tests; TBD exposes test debt that long branches hide.
  • "We have multiple supported versions." Use cherry-pick to release/x.y branches; trunk is forward-only.

The cultural component

TBD is as much a culture as a workflow. It assumes engineers can land small, safe, well-tested changes daily. It rewards investment in test speed and observability. Teams that adopt the workflow without the culture get burned; teams with the culture do not need a heavy branching model.

If your CI is fast and your changes are small, TBD is the lowest-overhead workflow that still produces shippable software every hour.