A merge conflict is not created by merging — it is created by divergence and merely discovered by merging; hundreds of long-lived branches = an organization accumulating undiscovered conflicts for months. Trunk-based flips this: integration is continuous, and unfinished work hides behind flags (72), not behind branches. A branch lives for days, not sprints.
The practice is older than the name: continuous integration originally meant everyone integrating into mainline at least daily, and Humble and Farley’s Continuous Delivery (2010) builds on that. Paul Hammant’s trunkbaseddevelopment.com collected the variants. The evidence is DORA’s: in Accelerate (2018) Forsgren, Humble and Kim report that having fewer than three active branches, merging them within a day and having no code freeze correlated with higher delivery performance in their surveys. That is correlation in survey data, not a controlled experiment; teams that can merge daily may also be better in other ways.
The mechanics without which trunk-based falls apart at 80+ services: a merge queue (PR batches are tested in their future merge order, not against a stale main — otherwise “green PR, red main” happens daily) plus required checks faster than 10–15 minutes: slow CI recreates long-lived branches economically, because frequent integration becomes expensive for people. Flags instead of branches move the risk from “conflict at merge” to flag debt (72) — a deliberate trade; the latter is cheaper because it is visible.
Not expressible in code; expressed through repository policy and, above all, CI speed — trunk-based is first and foremost an SLO on the build.
Where branches are right. Open source with untrusted contributors needs forks and review before anything reaches main. Supported release lines — a 2.x that still gets security fixes — are long-lived branches by design; fixes land on trunk first and are cherry-picked back. The merge queue’s idea is Graydon Hoare’s “not rocket science rule”: automatically maintain a repository that always passes all its tests, by testing each change as it would be merged.