--- title: "When I Switch to Trunk-Based Development" description: "Why release branches break for high-frequency deploy teams and how much of trunk-based is really discipline — the thresholds I cross and the ones I don't" url: https://sade.dev/en/journal/when-i-switch-to-trunk-based/ lang: en author: "Muhammet Şafak" published: 2026-05-23 updated: 2026-09-06 section: Journal tags: ["git","workflow","deploy","decisions","opinion"] summary: "Trunk-based development is a cadence decision, not a tool. Below five deploys a week the release branch is still order; above it the branch becomes the obstacle, because merge friction does not grow linearly and the hotfix port back to develop eventually gets forgotten. It only works on four foundations: a CI-guaranteed green trunk, feature flags, a pipeline under ten minutes, and branches that close within a day." --- # When I Switch to Trunk-Based Development > Trunk-based development is a cadence decision, not a tool. Below five deploys a week the release branch is still order; above it the branch becomes the obstacle, because merge friction does not grow linearly and the hotfix port back to develop eventually gets forgotten. It only works on four foundations: a CI-guaranteed green trunk, feature flags, a pipeline under ten minutes, and branches that close within a day. 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](/en/journal/gitflow-vs-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](https://www.muhammetsafak.com.tr/blog/production-git-senior-pratik-rehberi/); 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](/en/journal/gitflow-vs-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. ## Frequently asked **When is it worth switching to trunk-based development?** Once deploy frequency passes five per week, the release branch stops being order and starts being an obstacle; the projects where I argue for trunk-based run at three to ten deploys a day. A team that deploys once a week has no compelling reason to move — Gitflow or GitHub Flow works fine at that rhythm. **What has to be in place before switching?** Four things. A green trunk guaranteed by CI, because a broken trunk is the moment everyone is blocked. Feature flag infrastructure, so unfinished work can live in the code while staying closed to users. A pipeline that gets from merge to prod in five to ten minutes. And a culture where a branch closes the day it opens or the next one. Without all four, trunk-based speeds up incidents rather than delivery. **When do I not switch to trunk-based?** In four cases. A regulated industry where a compliance gate makes the release branch a legal rather than a technical requirement. Parallel version maintenance, where 3.x and 4.x have to be supported at the same time. A team that cannot guarantee a green CI. And a team smaller than three deploying once a week, where the investment never pays off. ## Sources - [Trunk Based Development](https://trunkbaseddevelopment.com/) — Paul Hammant - [DORA capabilities: Trunk-based development](https://dora.dev/capabilities/trunk-based-development/) — DORA - [DORA software delivery metrics](https://dora.dev/guides/dora-metrics-four-keys/) — DORA