When I Switch to Trunk-Based Development

Friday afternoon, the sixth deploy of the day is going to prod. A hotfix taken from the release/2026.05 branch collides with the previous hotfix as it’s merged back into develop. A three-person channel opens, ten minutes of talk, and nobody stops to think “this is actually a trivial conflict” — because it’s the fourth one this week.

If the scene feels familiar, your branching strategy can’t keep up with your deploy cadence.

Trunk-based, in one sentence

A single long-lived branch (main or trunk), feature branches whose lifespan is measured in hours — two days at most — and a cadence where every merge is kept green enough to ship to prod. Unfinished features live in the code and are exposed to users behind a feature flag.

Nothing more — no release/* branch, no develop branch, no long-lived branches tied to a version number.

What counts as “high frequency”?

It’s meaningless without being concrete: the projects where I argue for trunk-based all share one trait — 3 to 10 deploys a day. A team that deploys once a week has no compelling reason to move to trunk-based; Gitflow or GitHub Flow works fine at that rhythm.

For me the threshold is clear: once deploy frequency hits 5+ per week, the release branch stops being “order” and starts being an obstacle.

Why does the release branch break at high frequency?

Three real mechanisms:

• Merge friction doesn’t grow linearly. The longer two branches live side by side, the higher the chance of conflict grows with each passing day. In a weekly release cycle this stays invisible; in a daily cycle every merge is a small drama.
• The hotfix path creates a parallel history. hotfix/* → main → ported back to develop. Forgetting that port is the single most common source of prod bugs; at high frequency, never forgetting is statistically impossible.
• The distance between review and deploy widens. If there are days between the moment a PR is “merged” and the moment it lands in prod, code review is actually evaluating a staging environment, not prod. The two environments are not the same thing.

The real cost of this workflow: discipline

Trunk-based isn’t “let’s delete branches.” It’s a discipline that binds a piece of code’s journey from birth to retirement — the software lifecycle — to a tighter cadence. Trunk-based without that discipline just means a prod that breaks faster.

Don’t try it without these:

1. A green trunk, at the contract level. A broken trunk = the moment everyone is blocked. Without CI that guarantees this (a fast, reliable test pyramid + mandatory PR checks), trunk-based is a fantasy.
2. Feature flag infrastructure. Half-finished features entering the code while staying closed to users is the foundation of this model. From a boolean flag to profile-based rollout, a feature flag discipline is mandatory.
3. A fast pipeline. If it takes 30 minutes from merge to prod, the claim that “every merge can ship to prod” is theoretical. The 5–10 minute range is the practical threshold.
4. A short-lived branch culture. Merging a PR after 4 days isn’t trunk-based, it’s Gitflow in disguise. A branch should close the day it opens, or the next day.

If these four aren’t in place, forcing trunk-based on a team doesn’t speed up prod — it only speeds up prod incidents.

You’ll hear “code review slows you down”

It doesn’t slow you down, it breaks the work into pieces. Trunk-based PRs are small by design — 200 to 400 lines, a single logical change. At that size a review takes 60 to 90 minutes. Anyone who knows that nobody actually reads a 2,000-line PR will see the real gain in moving to small PRs.

A small PR plus a feature flag separates “is this feature visible in prod” from “does this code compile in prod.” They’re two different decisions; trunk-based forces the distinction.

When do I not switch?

The same checklist applies in reverse. The scenes where I don’t move to trunk-based:

• Mandatory pre-prod sign-off in a regulated industry. If a release has to pass a compliance gate, the release branch is a legal requirement, not a technical one. Trunk-based can’t carry it.
• Maintaining parallel versions. If 3.x and 4.x have to be supported at the same time — a packaged product, an SDK, an on-prem distribution — Gitflow’s version line is the natural answer.
• No CI maturity. Trunk-based dumps the cost of a broken main branch onto the team. On a team that can’t guarantee a green CI, that cost is paid as 1–2 hours of wasted time a day.
• A team smaller than 3, deploying once a week. The investment doesn’t pay off; your current pain isn’t solved by trunk-based because it doesn’t exist in the first place.

The metrics I use to measure the switch

“It’s going well” can’t be a hypothesis, it has to be measured. I read whether trunk-based is working from these three metrics:

• Lead time for changes — the p50 time from commit to prod. My target is < 1 hour.
• Change failure rate — what percentage of changes shipped to prod require a rollback or hotfix. My target is < 15%.
• Mean time to restore — how many minutes it takes to fix something that broke. My target is < 30 minutes.

If these three start going the wrong way, before abandoning trunk-based I review the CI and flag discipline — the cause is almost always there.

A workflow alone isn’t a silver bullet

Trunk-based, Gitflow, or GitHub Flow — none of them fixes your prod on its own. In production, branching strategy, code review cadence, deploy automation, and rollback readiness are a whole that works together. I compiled the branch strategy and commit/review hygiene side of that whole earlier in Git in Production: A Senior’s Practical Guide; trunk-based is the end of that picture where the cadence is fastest.

To help you decide where you fall between the two extremes, I covered the choice between Gitflow and GitHub Flow in a separate post.

---

Trunk-based isn’t a tool, it’s a cadence decision. Whatever rhythm your deploy frequency settles into, your workflow should settle there too — not the other way around.

Choose your workflow by prod’s pulse, not by fashion.