Trunk Based Development

Trunk-based development is a version control strategy in which all developers work on a single long-lived branch — the trunk (usually called main). Changes are integrated frequently, often multiple times a day, keeping the trunk in a continuously deployable state.

How It Works

Developers may work directly on the trunk or, more commonly in larger teams, create very short-lived feature branches (lasting hours, not days) that are merged back into the trunk via a pull request. The key constraint is that no branch lives long enough to drift significantly from the trunk. This keeps merge conflicts small and infrequent.

Feature Toggles

Because code lands in the trunk before it is fully complete, feature toggles (also called feature flags) are essential. A toggle lets you ship code to production without making it visible or active for users. When the feature is ready, you flip the toggle on. If something goes wrong, you flip it off — no rollback or revert needed.

Feature toggles are what make trunk-based development safe for teams that are not yet confident enough to merge finished features only.

Pair Programming

Pair programming pairs naturally with this strategy. When two developers work on the same code at the same time, they share context in real time. This reduces the chance of integration surprises and accelerates knowledge sharing across the team. It is one of the reasons trunk-based development works well even in teams where individual developers are still learning the codebase.

Continuous Integration

A mature CI pipeline is not optional in trunk-based development — it is a prerequisite. Every commit to the trunk must trigger an automated build and test run. If the tests fail, the trunk is broken and the whole team is affected. Fast, reliable CI is what makes the "integrate often" philosophy workable at scale.

Advantages

• Simple mental model. There is one branch to think about. No long-lived feature branches to rebase, no release branches to manage.
• Fast feedback. Code reaches production quickly, which means real users exercise it quickly. Bugs surface early, when they are cheap to fix.
• Small, reviewable changes. Because branches live for hours rather than days, each pull request is small. Reviews are fast and confident.

Disadvantages

• Requires discipline. Merging broken code into the trunk affects everyone. The team must be committed to keeping the trunk green at all times.
• Feature toggles add complexity. Managing toggles — creating them, maintaining them, cleaning them up after a feature ships — is overhead that does not exist in branch-heavy workflows.
• Less suited to scheduled releases. If your organisation needs to plan and coordinate a release date with specific features included, trunk-based development makes that harder than a model with release branches.

When to Use It

Trunk-based development is the default strategy for teams that deploy continuously and have confidence in their automated test coverage. It is also the strategy that scales best as teams grow — the alternative (long-lived feature branches) becomes increasingly painful as the number of concurrent branches rises.