Trunk Based Development

How Large Pull Requests Are Killing Your Delivery Speed#

In many software teams, the pattern is all too familiar: a developer works for days on a feature branch, opens a pull request with hundreds of lines changed, and waits for someone to find time to review it. The PR sits in the queue. The review becomes superficial. The merge to main is postponed. The release becomes a project in itself.

Trunk Based Development (TBD) is a direct answer to this problem. It is a branching strategy where all developers integrate into one shared branch—the trunk, or main—multiple times a day. It sounds simple, and it is. But the implications are significant.

The Problem with Large Pull Requests#

From Feature Branch to Isolation Chamber#

Feature branches were introduced to provide isolation: work independently without disrupting others. What starts as a convenience quickly becomes a silo. Developers work for weeks on their own branch while the distance from main keeps growing.

When the PR is finally opened, the scope is overwhelming: hundreds of changed files, thousands of lines of diff, business logic mixed with refactoring and bug fixes. Meaningful review becomes impractical.

A PR with 1,000 lines is not a Pull Request. It is a surrender.

Reviews That Mean Nothing#

Large PRs are not reviewed seriously. It takes too long. Reviewers scroll through the diff, leave surface-level comments, and approve to clear the queue. The quality gate that review was meant to provide evaporates.

The consequences accumulate quietly. Architectural mistakes are discovered late. Business logic is not understood by the rest of the team. Technical debt is introduced and immediately forgotten. Knowledge stays in individual developers' heads.

What was designed as a safety mechanism becomes a rubber stamp.

Large PRs Lead to Late Releases#

The Merge Becomes a Project#

The longer a branch lives, the greater its divergence from main. A merge after two weeks almost guarantees conflicts—not just syntactic ones, but semantic ones: two developers who modified the same logic independently and incompatibly.

The merge itself takes hours. Then comes a round of testing to verify that nothing broke. The "ready to release" state keeps moving further away.

Release Anxiety#

In teams with long-lived branches and large PRs, release anxiety is predictable. The question "are we ready to release?" is met with hesitation, because nobody knows exactly what the release contains. So much changed at once that regression risk feels real.

Teams release less frequently as a result. And the less frequently they release, the more changes accumulate in the next release, which makes the next release scarier. A vicious cycle forms where releasing becomes something to dread rather than something routine.

Nobody Merges to Main Anymore#

Long-lived branches create a culture of avoidance. Developers stop merging to main regularly because they fear what they will find. Integration becomes a rare, high-stakes event.

The consequences compound. The main branch no longer reflects the actual state of the codebase. Continuous integration becomes meaningless. The team loses the habit, and eventually the confidence, to ship.

This is the paradox of trying to reduce risk through isolation: the longer you wait, the more risk you accumulate.

Trunk Based Development as the Solution#

TBD flips this dynamic. Developers work in small, focused increments and push to main—or to short-lived branches merged within hours, not days. Every push triggers the CI pipeline. Every integration is a small, verifiable event.

PRs stay small enough to review meaningfully (under 200 lines is a reasonable target). Reviewers can engage with the intent of the change, not just its surface. Merge conflicts are rare. The main branch is always in a releasable state.

Feature Flags as an Enabler#

A common objection to TBD: "My feature isn't finished. I can't ship half a feature."

Feature flags resolve this. Incomplete work is merged behind a flag that is off in production. The code integrates continuously. The feature is enabled when it is ready. Development and deployment are decoupled.

Releasing Without Anyone Noticing#

Frequent, small releases enable deployment without disruption. On a Kubernetes-based infrastructure with zero-downtime deployment configured, you can release multiple times a day without consumers observing anything.

The mechanism is pod lifecycle management:

Old pods:   [v1] [v1] [v1]
Deploying:  [v1] [v1] [v2]   <- new pod starts taking traffic
Done:       [v2] [v2] [v2]   <- old pods terminated

Rolling deployments and blue/green strategies transform a release from a high-risk event into a routine operation. When releases stop being events, teams stop being afraid of them.

Repetition Builds Capability#

There is a second-order effect that is easy to overlook. Safe deployment requires a pipeline that actually works: health checks configured correctly, readiness probes in place, fast rollback available. Most teams do not have this from day one.

Every deployment tests the pipeline. Deploying once a month means problems surface infrequently and are fixed slowly. Deploying ten times a week means problems surface constantly and are fixed quickly. Teams that deploy daily have better pipelines than teams that deploy monthly—not because they started with better infrastructure, but because they improved it through repetition.

Making the Shift#

Moving to TBD is not just a tooling change. It requires:

• Small commits: Every commit is a coherent, reviewable unit of work.
• Trust in CI: A passing build is sufficient to merge.
• Operational readiness: Health checks, rollback strategy, and monitoring in place before scaling up deployment frequency.
• Feature flags: Incomplete work merged behind flags, separating deployment from feature activation.

The reward is real. Teams that practice TBD release more often, with less stress, with higher confidence, and with a much tighter feedback loop between writing code and observing it in production.

The goal is not speed for its own sake. The goal is to make releasing so routine, so small, and so safe that it stops being something you plan for and becomes something you simply do.

"If it hurts, do it more often." — Jez Humble, Continuous Delivery