Trunk-based development is the branching model that consistently correlates with elite DevOps performance in the DORA research.
Trunk-based development (TBD) is a source-control strategy where developers collaborate on a single branch (main / trunk) and merge to it at least once per day. Long-lived feature branches are avoided; incomplete features are hidden behind flags. It stands in contrast to GitFlow and other multi-branch strategies that were designed for infrequent, high-ceremony releases. For modern SaaS shipping multiple times per day, TBD is the higher-performing default.
A branch that lives for two weeks accumulates divergence from main. Merging back requires reconciling every change in between, running full regression, and often finding integration bugs late — exactly when the cost to fix is highest. Two engineers working on adjacent long-lived branches will step on each other's code without knowing. The DORA research is unambiguous: teams that integrate to main daily have higher deployment frequency, lower change failure rate, and faster recovery from incidents than teams that batch.
Every developer's working branch is short-lived — hours to a day, never more than two days. PRs are small (ideally under 400 lines of diff), reviewed within hours, merged the same day. Incomplete features ship behind a flag defaulted to off; a flag flip becomes the release event. CI runs on every PR and on main after merge; a broken main is a stop-the-line event with the last committer responsible for the fix. Release branches, when used at all, are cut from main just before release, receive only critical fixes cherry-picked from main, and are short-lived themselves.
(1) A strong CI system that runs in under 15 minutes and is reliable enough that a green build means green code. (2) Feature flags in place before adopting TBD — you cannot ship unfinished features to main without them. (3) A test suite that catches regressions with high confidence (unit + integration; some end-to-end for critical flows). (4) Code review culture that responds within hours, not days. (5) Team agreement that main is always deployable. Adopting TBD without these prerequisites produces broken main, blocked developers, and a backlash toward heavier branching.
The feature flag is the primary tool: land code behind a flag defaulted off, iterate over multiple PRs, enable the flag when ready. For refactors that cannot be flagged (schema changes, API renames), use the strangler pattern — add the new path alongside the old, migrate callers incrementally, remove the old path last. Never merge a broken but unflagged path to main — it violates the 'main is always deployable' contract that TBD depends on. If work truly cannot be broken up, that is a design signal to break it up before starting.
Migration steps: (1) Set up feature flags first — one platform, one boolean flag adopted successfully. (2) Reduce branch lifetime — set a policy that any branch older than 3 days is escalated. (3) Delete the develop branch — merge develop into main, then rebase all open PRs on main, then delete. (4) Enforce PR size limits in code review — anything over 400 lines gets pushback. (5) Move release cut to main directly. Expect a 4-8 week adjustment period; friction is high in week 1 and drops fast as the muscle builds.
Investor directory · Fundraising library · Articles A–Z · Company funding database