Trunk-Based Development

How a team uses branches in version control has a surprisingly large effect on how fast it can deliver. When developers work on long-lived feature branches, their changes drift apart, merges become slow and risky, and finished work waits for a release branch to be cut and stabilized. Trunk-based development takes the opposite approach. Everyone works off a single main branch, called the trunk, and merges small changes into it at least once a day. Any branches that do exist are short-lived, usually lasting hours or a day or two, so the trunk is always close to what everyone is working on. Small teams may commit directly to the trunk, while larger teams typically use short-lived branches with quick code review before merging.

The practice has been used at large technology companies for many years and is described in detail by Paul Hammant and others. It contrasts with branching models such as Gitflow, published by Vincent Driessen in 2010, which use long-lived develop, feature and release branches. DORA research has found that trunk-based development, with few active branches and frequent merges, is associated with higher delivery performance. For developers, tech leads and engineering managers, it is one of the most practical changes a team can make to speed up delivery.

Definition of Trunk-Based Development

Trunk-based development is a version control branching model in which all developers integrate their work into one shared branch frequently, with any feature branches kept small and short-lived, and with unfinished features hidden behind feature flags rather than kept on separate branches.

It is closely tied to continuous integration, depends on feature flags to manage incomplete work and supports continuous delivery.

How It Works

Developers break work into small changes that can be merged safely, often several per day.

Changes are merged directly to the trunk or through short-lived branches with pull requests that are reviewed quickly.

Every merge triggers automated builds and tests, so the trunk stays healthy.

Features that are not ready for users are merged behind flags and switched on when complete, so code can be integrated before it is released. Releases are made from the trunk itself, or from short-lived release branches cut from it when a fixed version is needed.

Trunk-Based Development vs Gitflow

Gitflow uses a long-lived develop branch, feature branches for each feature and release branches for each version. It suits software released in distinct versions, such as packaged products.

Trunk-based development uses one main branch and very short-lived branches. It suits services that are deployed continuously.

The main difference is how long work stays apart. In trunk-based development, changes are integrated within a day; in Gitflow, they may stay apart for weeks. Some teams that ship versioned software still use trunk-based development, cutting release branches only at the last moment and fixing bugs on the trunk first.

Importance of Trunk-Based Development in Delivery and Engineering Operations

Trunk-based development reduces merge pain. Small, frequent merges rarely conflict, and when they do, the conflicts are small and easy to resolve.

It keeps code releasable. Because all work is integrated and tested continuously, the trunk can be released at any time without a stabilization phase.

It also speeds up feedback. Developers see each other's changes within hours, so design problems and duplicated work are spotted early. It simplifies the branching model itself. With one main branch, there are fewer rules to remember and fewer places for changes to get lost.

Trunk-Based Development and Financial Management

Less time spent resolving merge conflicts and stabilizing release branches means more engineering time for new work.

Finished work reaches customers sooner, shortening the time before development spending produces value.

Smaller changes reduce the cost of defects, since each problem is easier to find and fix.

Feature flag tools and stronger test automation may require investment, which is usually repaid through faster, more reliable delivery.

Common Challenges

Teams without good automated tests may break the trunk often. Strong continuous integration is a prerequisite.

Developers used to large feature branches need to learn to split work into small, safe steps, which takes practice.

Feature flags that are never removed create clutter and technical debt. Teams should remove flags once features are fully released. Code review can become a bottleneck if reviewers are slow, so teams need to treat reviews of small changes as a priority.