What Is Trunk-Based Development and Why Teams Switch

What is trunk based development? It is a branching strategy where every developer merges to a single shared branch, usually called main or trunk, at least once a day. There are no long-lived feature branches. Code lives in production-ready state at all times. If a feature is not ready, a feature flag keeps it hidden from users, not a branch keeping it isolated from the team.

That is the short version. The longer version involves why your current workflow might be generating more risk than you realize.

Why long-lived branches become a liability

Most teams learn version control through feature branches: one branch per ticket, merged after review. It feels organized.

When a branch lives more than 24 hours, every commit your colleagues make to main is a future conflict you have not seen yet. On a team of eight engineers each holding a two-week branch, you are not running one integration. You are managing eight parallel worlds that diverge a little more each day. Merge day is not a task. It is a negotiation.

The DORA research, the largest longitudinal study of software delivery performance conducted across thousands of teams, draws a hard line here: branches that live longer than 24 hours are a predictive signal for lower deployment frequency and higher change failure rates. Elite-performing teams integrate multiple times a day. The rest merge when the feature is "done," which often means never cleanly.

The hidden cost is not the merge conflict itself. It is the context-switching required to resolve it three weeks after the code was written. No one remembers what the intent was.

How trunk-based development actually works

The mechanic is straightforward. You pull main. You make a small, coherent change. You run the test suite. You push to main. All of this happens before you leave for lunch.

For a solo contributor on a small repo, this is already how things work. For a team of twenty on a 300K-LOC monorepo, it requires three practices working together:

Short-lived branches (optional but common): Some teams allow branches up to two days before forcing a merge. This preserves code review culture without creating multi-week divergence. The branch is a review vehicle, not an isolation mechanism.

Continuous integration on every push: Every commit to main triggers a full build and test suite. If it breaks, it breaks in minutes, not after a two-week feature branch lands at Friday 4pm.

Feature flags for incomplete work: Unfinished features ship to production behind a flag. Users see nothing. The team integrates everything. This is the piece most teams skip, which is why their first TBD experiment fails.

None of these practices is exclusive to trunk-based development. The difference is that TBD makes all three mandatory rather than optional.

Feature flags: the mechanism that makes TBD work

A feature flag is a conditional in your code that evaluates at runtime. When a flag is off, the new code path does not execute. When it is on, for a specific user, a percentage of traffic, or the whole user base, it does.

This sounds trivial. The implication is not: you can separate deployment from release. Code ships to production continuously. Features launch when they are ready, or not at all if the rollout goes wrong and you need to kill it in ten seconds rather than roll back three weeks of commits.

The minimum viable setup requires three things: a way to define flags, a way to evaluate them at runtime, and a way to change them without redeploying. A flat JSON config file works for a team of three. A dedicated feature management service earns its complexity somewhere around ten engineers or when flags start needing targeting rules like "enabled for users in the beta cohort in Germany."

One thing to track: flag debt. Flags that never get cleaned up after the feature ships become conditional spaghetti. A team doing TBD correctly retires each flag within one sprint of the feature being fully rolled out. Treat flags as temporary scaffolding, not permanent configuration.

TBD vs Gitflow: a direct comparison for 2026

Gitflow was designed in 2010 for boxed software shipped on a quarterly cycle. It models releases as long-lived branches. For teams that deploy every day or every hour, that model no longer maps.

Here is what the comparison looks like for a team running CI/CD:

Branch lifetime: Gitflow runs days to weeks. TBD runs hours to a maximum of 1-2 days.

Merge conflicts: Gitflow produces frequent, high-severity conflicts. TBD produces rare, low-severity ones because integration gaps are hours, not weeks.

Deploy frequency: Gitflow ties deployment to a release branch. TBD decouples deployment from release entirely.

Rollback mechanism: Gitflow rolls back by reverting a branch merge. TBD rolls back by turning a feature flag off.

Onboarding complexity: Gitflow requires understanding develop/main/hotfix conventions. TBD has one branch: main.

Required CI investment: Gitflow is low (branches absorb the risk). TBD is high (main must stay green at all times).

Gitflow is not wrong in every context. If you ship a mobile app to an App Store and cannot push hotfixes in minutes, a release branch model makes sense. If you run a SaaS where you control deployments, the extra branching structure is overhead that adds coordination cost without adding safety.

What DORA metrics say about branching strategies

The DORA State of DevOps research has tracked software delivery performance since 2014. Two findings from the data are directly relevant here.

First, trunk-based development is one of the 24 capabilities that predict software delivery performance in the DORA model. It sits under the "continuous delivery" cluster, which means DORA treats it as infrastructure practice, not team preference.

Second, elite-performing teams deploy multiple times per day. Low performers deploy once per week or once per month. Long-lived branches and infrequent integration appear at the slower end of that distribution across multiple years of data.

What the research does not claim: that TBD causes elite performance. Teams that adopt TBD successfully tend to already have automated testing, a working CI pipeline, and a habit of small commits. Trunk-based development surfaces those gaps immediately if they are missing. A team with no CI and 40% test flakiness will not benefit from switching to TBD. They will just break main more often.

Where trunk-based development stops making sense

Three scenarios where TBD creates more problems than it solves:

Heavily regulated environments with mandatory pre-release approval gates: If every release needs a compliance sign-off before it can ship, continuous deployment to production is blocked anyway. The branching model becomes secondary. You will batch changes regardless of branching strategy.

Underpowered test suites: TBD requires a fast, reliable CI pipeline. If builds take 45 minutes and have 20% flakiness, developers will batch commits to avoid waiting. That defeats the model. The constraint is the test infrastructure, not the branching convention.

Very large teams with inconsistent code ownership: On teams of 50+ where each squad owns a distinct service, TBD works well at the service level. Applying it across a shared monorepo where everyone touches everything requires strict linting conventions and CI ownership rules to keep main clean.

In all three cases, the fix is not a different branching strategy. The fix is the underlying infrastructure problem. TBD just makes that problem visible faster.

How to migrate without stopping deliveries

The migration most teams get wrong: they announce TBD, delete the feature branch convention, and watch main break in the first week.

A safer path:

1. Keep existing branches, add a lifetime rule: No branch lives more than 3 days. This forces the pressure of frequent integration without turning off the lights.

2. Instrument your CI first: Before merging goes fast, merging must be safe. Make sure the test suite is green, runs in under 15 minutes, and blocks the main branch on failure.

3. Pick one feature to gate with a flag: Build the flag management muscle before you need it for every unfinished feature.

4. Shrink branch lifetime week by week: From 3 days to 2 days to 1 day over six weeks. Track merge conflict frequency as a leading indicator. When it drops, the model is working.

5. Retire the old convention only when the new one works: Gitflow conventions stay in place for anything outside the pilot. Running both models for 6-8 weeks is fine.

The one habit that predicts whether TBD will stick

Trunk-based development does not fail because teams cannot merge to main. It fails because developers are not in the habit of scoping work small enough to ship in a day.

The underlying shift is not technical. It is how work gets defined in planning. A story that says "implement the new payment flow" is a two-week branch waiting to happen. A story that says "add the route handler and return a 501 behind flag payment-v2" is a half-day commit.

This requires PM involvement and backlog hygiene that most teams have not built. The branching strategy change takes a day to announce. The scoping discipline takes six months to build.

If your team already ships working software to production daily, TBD formalizes what you already do. If your team ships every two weeks with a big-bang merge at the end, TBD will not be comfortable until the delivery habits underneath it change.

The teams that stick with TBD are the ones that invested in three things before switching: a sub-15-minute CI pipeline, a working feature flag service, and sprint ceremonies that produce stories small enough to close in a day. Without those three, the branching convention is the wrong lever.

Tools that help teams run TBD workflows

Running trunk-based development at the team level means more synchronous alignment: quick standups to catch integration drift, documented conventions for flags and CI rules, and calls for pair-review on critical paths.