# trunk-based-development

**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 [[no-silver-bullet-llms|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).

## Related

- [[stop-using-pull-requests]] — the larger argument in which TBD is the integration leg
- [[ship-show-ask]] — Wilsenach's three-way change classification that makes TBD compatible with lightweight optional review
- [[code-review-knowledge-transfer]] — what review is *actually* for, which determines whether async blocking review can survive in a TBD workflow
- [[pair-programming]] — the team-level review mechanism that lets TBD work without post-hoc gating
- [[stacked-prs]] / [[billjings-git-not-fine]] — git's workflow gaps that TBD sidesteps by not depending on long branches