trunk-based-won

Integration pain grows faster than linearly with how long branches diverge — so every branching model is really a bet on how long you can afford to not know whether your work combines.

The models and their fatal failure modes

model	shape	how you fatally shoot yourself
trunk-based	everyone integrates to one branch continuously; incomplete work hides behind flags	break trunk and everyone is broken now; ship a half-finished feature because no structure stopped it — the forgotten flag becomes the outage
git-flow	long-lived develop, feature/release/hotfix branches	merge hell: weeks of divergence, each branch green alone, the combination never tested until a multi-day merge; bugs exist only in the combination; what you test ≠ what you ship
GitHub flow	short branches off main, PR back within days	mild; degrades into git-flow's failure if branches quietly live for weeks
release branches	long-lived branch per shipped version	cherry-pick drift: the fix lands on one branch and not the other; the "fixed" bug ships in a supported version
stacked PRs	chain of dependent branches, reviewed separately	bookkeeping fragility: rebase cascades, and the closing propagation to trunk is manual — see stacked-prs-strand-main

What the evidence says

• DORA / Accelerate (Forsgren, Humble, Kim — multi-year, tens of thousands of respondents): trunk-based practice (≤3 active branches, branch life under ~a day or two, no code freezes) predicts better deployment frequency, lead time, change-failure rate, and recovery time — speed and stability improved together, not as a trade-off. Correlational-plus-longitudinal, but the strongest empirical base any branching claim has.
• XP-era CI (late 1990s) made the core observation first: integration cost grows nonlinearly with divergence time, so integrate daily.
• Google and Meta are the largest natural experiments: tens of thousands of engineers on a single trunk for decades, made safe by presubmit CI, feature flags, and rollback tooling — the safety budget moved from isolation into verification.
• Driessen himself (git-flow's author) added a 2020 header to the original post: if you deploy continuously, use GitHub flow instead; git-flow was designed for explicitly versioned, released software.
• Knight Capital's 2012 collapse (~$460M in 45 minutes) is the canonical trunk-based-without-the-discipline cautionary tale: a dead-code path plus reused flag on a partial deploy. (Characterization from memory — unverified against the SEC report.)

Sources with links: literature index.

What it means here

"Best" is conditional on one variable above all: how good your automated verification is, because trunk-based spends the safety budget on tests instead of isolation. This repo: every slice ships red-first with its tests, the suite runs in seconds, one developer, one reviewer, nothing versioned in parallel — every force points to short-lived slice branches off main, merged fast. The one big-league discipline worth importing as prototypes grow: if a slice can't finish in one branch-lifetime, land it dark (flagged off, like the desk station staying decor) rather than letting the branch live for weeks.