Every team that adopts trunk-based development has the same conversation in week one: “but how do we ship unfinished features?” The honest answer — the one most articles dance around — is that you ship them, behind a flag, invisibly. The release of the code and the release of the feature are two different events. Once that distinction clicks, everything else about trunk-based development falls into place.
The mechanical rules
- One long-lived branch:
main. That’s it. - Short-lived branches only. A feature branch that lives more than 24 hours is an emergency. 48 hours is a code smell.
- Main is always green. If CI on main fails, the team stops and fixes it before anything else merges.
- Unfinished work ships behind feature flags. The code merges; the feature does not light up.
- Deploy from main, multiple times a day.If you can’t, you have a CI/CD problem, not a process problem.
Why GitFlow stops working past 5 engineers
GitFlow was designed for desktop software with quarterly releases. Most modern teams ship continuously. The mismatch shows up as: long-lived release branches that drift from main, merge conflicts that scale with branch age, hotfix branches that bypass the integration testing the rest of the flow relies on, and the twice-a-quarter “release weekend” that gets ritualized into a thing nobody enjoys.
Trunk-based doesn’t fix this by making releases less risky — it fixes it by making them so frequent that no single one matters.
The four things you need to make it work
1. A fast, reliable CI
Trunk-based assumes you can verify a change in <10 minutes. If your CI takes 45 minutes, engineers will batch changes, and once batches form, the whole model collapses. Invest in CI before the process.
2. Feature flags
Adopt a real feature-flag tool (LaunchDarkly, GrowthBook, ConfigCat, or a homegrown DB-backed system — just pick one). Wrap every in-progress feature in a flag. Default off in production; on for the people working on it.
3. Code review that doesn’t block for days
A PR open for 3 days defeats trunk-based. Set the team norm: PRs reviewed within 4 working hours. If a PR is too big to review in 4 hours, it’s too big — split it.
4. The discipline to revert quickly
When main breaks, the answer is revert first, fix offline. The temptation is “I can fix this in 10 minutes” — resist it. Revert in 30 seconds, restore main to green, then fix at human pace.
Common objections, addressed
- “Our QA team needs a stable branch to test.” They need a stable environment to test. Use a staging environment, not a stale branch.
- “We can’t ship to prod multiple times a day.” You can deploy multiple times a day without releasing anything new — the code is there, the flags are off. Release pace and deploy pace are independent.
- “Feature flags are tech debt.” They are, if you leave them. Every flag should have a removal date in its issue tracker entry. Clean them up within 90 days of GA.
How we approach this
Every team we set up via SaaS Product Development ships trunk-based from day one. The CI is fast (cached and parallel), the flags are in place before the first feature lands, and PRs are kept small enough to merge within a day. The team velocity that compounds from this is the single biggest dividend we’ve seen across engineering processes.
Takeaways
- One long-lived branch. Short-lived everything else.
- Feature flags decouple deploy from release.
- Fast CI + fast code review = trunk-based actually works.
- Revert first, fix offline. Always.
