Trunk-Based Development

Paul Hammant's definition: everyone integrates to trunk daily, branches live hours not weeks, feature flags hide incomplete work.

Overview

What trunk-based development is

Trunk-based development (TBD) is the branching model where all developers commit to a single shared branch (trunk / main) at least once a day. Branches, when used at all, live hours, not weeks. The canonical reference is trunkbaseddevelopment.com (Paul Hammant, 2017+).

Hammant's definition: "Trunk-Based Development is a source-control branching model, where developers collaborate on code in a single branch called 'trunk' (in Git, this is the 'main' branch), resist any pressure to create other long-lived development branches by employing documented techniques."

Two flavors

Pure trunk-based — Every developer commits directly to trunk; no PRs; pre-commit local CI, post-commit team CI — Google (with extensive code review tooling), Facebook/Meta (Phabricator). Needs high test maturity and discipline; rare outside FAANG
Branch-based ("scaled" TBD) — A short-lived branch (hours to a day), PR, review, merge to trunk the same day. The branch is a pre-merge mechanism; the integration discipline is identical — The form most product teams adopt

Why it matters

DORA's research (Accelerate, 2018) consistently identifies trunk-based development as one of the strongest predictors of high software-delivery performance.

Fewer than 3 active branches, branch lifetimes under a day — Elite delivery performance
Long-lived feature branches, infrequent integration — Low performance

Compared with Git Flow and GitHub Flow

Git Flow (Vincent Driessen, 2010) — Long-lived develop and release branches plus feature and hotfix branches, tagged releases on main — Software with explicit release cadences: downloadable products, versioned libraries. Poor fit for SaaS and continuous delivery; Driessen's 2020 update says it was meant for versioned software, not web apps
GitHub Flow (GitHub, 2011) — Feature branches off main, PR for review, merge to main, deploy — Ranges from "TBD with PR review" (short branches, daily integration) to "TBD's enemy" (week-long branches with PRs nobody reviews)

> [!IMPORTANT] The branch lifetime is what matters, not the name of the model.

Feature flags make TBD viable

Feature flags let you merge incomplete work instead of parking it on a long-lived branch: incomplete code goes to trunk behind a flag, for example if (featureFlag.isEnabled('new-checkout', user)) { ... }. Pete Hodgson's 2017 Martin Fowler article on feature toggles is the canonical reference.

Key concepts

Trunk-based development (Hammant): Branching model where developers integrate to a shared trunk (main) at least daily, with branches living hours-to-a-day. Verbatim from trunkbaseddevelopment.com: "developers collaborate on code in a single branch called trunk."
Feature flag (Hodgson 2017): Boolean (or richer) gate around new code. Lets incomplete work merge to trunk behind a default-off flag. Categories: release toggles (release control), experiment toggles (A/B), ops toggles (kill switches), permission toggles (entitlements). Required for TBD on non-trivial features.
Branch by abstraction: Pattern for large refactors without long-lived branches: introduce an abstraction layer, migrate consumers behind the layer one-by-one, swap the implementation, remove the old code. All changes land on trunk. Avoids the "refactor branch" trap.
Git Flow (Driessen 2010): Branching model with long-lived develop, release, feature, hotfix branches. Designed for versioned software (libraries, downloadable products); poor fit for SaaS / continuous delivery. Driessen himself qualified the model in a 2020 update.
GitHub Flow: Simpler model: branches off main, PR review, merge, deploy. Compatible with TBD if branches stay short-lived; becomes anti-TBD when branches live for days. Branch lifetime is what matters.
DORA empirical evidence: Accelerate (Forsgren, Humble, Kim, 2018): teams with fewer than 3 active branches and branch lifetimes under a day correlate with elite delivery performance. Long-lived feature branches correlate with low/medium performance.

When to use it

Designing the branching strategy for a new product team — start at TBD, not Git Flow
Diagnosing slow delivery in a team with week-long feature branches and "merge week" pain
Justifying feature-flag platform investment to leadership — it is the engineering enabler for TBD
Migrating off Git Flow for a SaaS product where versioned releases are not the constraint

Interview questions

Define trunk-based development and contrast it with Git Flow.
How do feature flags enable trunk-based development for large features?
How do you migrate a team off Git Flow to trunk-based development?