Map

trunk-based-development

Wiki conceptsoftware-engineeringcontinuous-deliveryversion-control ↳ show in map Markdown
title
trunk-based-development
type
concept
summary
All developers integrate to a single mainline at least daily, in small batches, with feature flags managing incomplete work — the DORA-correlated practice that replaces long-lived feature branches
tags
software-engineering, continuous-delivery, version-control
created
2026-05-22
updated
2026-05-22

Trunk-based development (TBD) is the practice where every developer merges to a single shared mainline branch at least once per day, working in small batches and using feature flags to ship incomplete work without exposing it to users. It is the opposite of long-lived feature branching with delayed merges.

Paul Hammant's trunkbaseddevelopment.com codifies the practice. The constraints he names:

  • Ideal branch duration: 1 day maximum; smallest pieces ~quarter of a day.
  • Branches that last days or weeks are not TBD, regardless of what they're named.
  • Feature flags eliminate the "branches because the feature isn't finished" argument.

DORA evidence

The strongest industry signal sits inside DORA / Accelerate (Forsgren, Humble, Kim — 23,000 surveys across 2,000+ orgs, then 36,000+ professionals by the 2023 report). High-performing teams:

  • Have fewer than three active branches at any time.
  • Branches last less than a day.
  • No code freezes or stabilisation periods.
  • Elite performers meeting reliability targets are 2.3× more likely to use TBD.

The DORA capabilities framework explicitly calls out "heavyweight code review processes" as a barrier to TBD — they push developers toward larger batches and delayed merges. (See stop-using-pull-requests.)

The 2023 report adds: accelerating code review alone produces a 50% software delivery performance improvement. The mechanism: review speed is what determines whether a team can sustain daily integration.

Honest caveat: DORA data is correlational. High-performing teams may adopt TBD because they're already better, not the reverse. But the consistency across years of survey data is the strongest industry-scale evidence available.

Why it's hard

TBD requires preconditions that most teams don't have when they first hear about it:

  • Automated tests on every commit — without them, "merge daily" means "break trunk daily."
  • Feature flags infrastructure — needed to ship half-done features without exposing them.
  • Fast review — pairing, ship-show-ask, or non-blocking continuous review, since blocking async PRs make daily integration impossible.
  • Small batches as a skill — most developers default to commits big enough to need a PR; cutting them smaller is a habit, not a tool change.

The Minimum CD initiative (co-created by Jez Humble) is blunt: daily integration to trunk is non-negotiable. If your team is not integrating to trunk daily, you are not doing continuous integration. Most teams that think they're doing CI fail this test.

Position in the T*D triple

Laforgia (stop-using-pull-requests) groups TBD with TDD and pair/ensemble programming as the three components of T*D:

  • TDD builds quality into each line before it exists.
  • TBD keeps integration continuous, batches tiny, mainline always close.
  • Pair/ensemble programming relocates review from after development to during it.

The three reinforce each other. TBD without automated testing breaks trunk; TBD without small batches creates merge conflicts; TBD with blocking async PRs is logically impossible (you can't merge daily if reviews take days).

Linked from