Trunk-Based Development
also called TBD
All developers integrate small changes into a single shared branch at least daily, keeping it always releasable.
The argument for trunk-based development is not aesthetic. Merge pain grows superlinearly with branch age, because divergence compounds — two branches that each moved a week apart do not conflict twice as much as branches a day apart, they conflict far more, and the conflicts are semantic rather than textual.
It requires two things people underestimate. Changes must be decomposed so that an incomplete feature can sit on trunk harmlessly, which usually means feature flags, expand-and-contract schema changes and branch-by-abstraction for larger refactors. And the trunk must stay green, which means a broken build is the team's top priority, not a ticket.
The trade-off against long-lived feature branches is real for some contexts: shipping versioned software to customers who upgrade on their own schedule genuinely needs release branches. Continuous delivery to a service you operate does not.
Measured effect, consistently across the DORA research: integration frequency is one of the strongest correlates of both delivery speed and stability, which is the finding people find counter-intuitive until they see the mechanism.