Trunk-Based Development

practice · computer science · organizing-schema

Short-lived branches and frequent merges to a single trunk.

Trunk-Based Development is a source-control branching model in which all developers integrate their work to a single shared branch (the trunk, mainline, or master) at high frequency — typically multiple times per day — with branches kept short-lived (under a day or two) or eliminated entirely in favor of direct trunk commits with feature flags hiding incomplete work. The practice has roots going back decades — major engineering shops including Google, Facebook, and Amazon have used variants of TBD since their early days — but was codified as a named practice particularly by Paul Hammant and others in the 2010s, with Hammant's site (trunkbaseddevelopment.com) providing the canonical reference. TBD stands in deliberate opposition to GitFlow's model of long-lived develop, feature, and release branches, arguing that long-lived branches accumulate merge conflicts, hide work-in-progress from continuous integration, and slow feedback. The DORA research has consistently identified TBD as a practice associated with elite-performing teams, with high deployment frequency, low change failure rate, and short lead times. Feature flags (or feature toggles) are essential to TBD because they allow incomplete features to be merged without being exposed.

Originators

Long-standing practice at Google, Facebook, Amazon, and similar shops; Paul Hammant (named codification); Jez Humble and Dave Farley (Continuous Delivery argument for TBD) high

Year / Decade

Long-standing practice; 2010s codification; trunkbaseddevelopment.com publication ongoing high

Primary sources

Hammant, P. (ongoing). Trunk Based Development (trunkbaseddevelopment.com), Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate, Humble, J. & Farley, D. (2010). Continuous Delivery high

Core components

Single shared trunk/mainline branch
Short-lived branches (under 1-2 days) or direct trunk commits
High-frequency integration (many times per day)
Feature flags for hiding incomplete work
Pre-merge or post-commit code review
Comprehensive automated test coverage
Connection to continuous integration and continuous delivery
Distinction from GitFlow and other long-branch models

Primary use case

Software development at scale where rapid integration matters (most internet companies); foundation for high-deployment-frequency practices (continuous deployment); basis for elite-team DORA metrics; reference practice for organizations seeking to move from long-branch models; common model in monorepo-based organizations.

Common criticisms

Requires comprehensive automated test coverage that not all teams have — TBD without good tests is dangerous
feature flag infrastructure is itself non-trivial to build and maintain at scale
works less well in regulated environments where releases require formal sign-off and gating
some open-source projects have legitimate reasons for long-lived branches (release stabilization, maintenance branches) that TBD's purity arguments ignore
the discipline of small, frequent commits is harder than it appears, particularly for junior engineers or those used to long-branch workflows
transition from GitFlow to TBD is culturally difficult
not all TBD claims about productivity and quality benefits are well-validated outside of specific large-tech-company contexts.

Lineage

Siblings: GitFlow, CI/CD