What is Trunk-Based Development?

Trunk-based development (TBD) is a source control branching model in which all developers merge their code to a single shared branch — the trunk or main — at least once per day. Feature branches, if used at all, are short-lived (hours to a couple of days) and never diverge far from the trunk. This approach is the foundation of Continuous Integration and is strongly correlated with high software delivery performance in DORA research.

Why Trunk-Based Development?

Long-lived feature branches are the primary cause of integration problems. The longer a branch lives, the more it diverges from the trunk, and the more complex and painful the eventual merge becomes. Trunk-based development eliminates this risk by making integration a continuous activity rather than a periodic event.

Core Practices

• Everyone commits to the trunk at least once per day
• Feature branches are short-lived — hours to two days maximum
• The trunk must always be in a releasable state
• Incomplete features are hidden behind feature flags, not kept on branches
• Comprehensive CI runs on every commit to the trunk
• Build failures are the team's top priority to fix immediately

Trunk-Based Development vs GitFlow

Feature Flags Enable Trunk-Based Development

The most common objection to trunk-based development is "we cannot merge incomplete features to main." Feature flags solve this: developers merge code continuously but wrap incomplete functionality in a flag that is disabled in production. The flag is enabled when the feature is ready to ship, independent of the deployment timeline.

Scaled Trunk-Based Development

At large organizations with many developers, short-lived feature branches merged to trunk via pull requests are the practical implementation of trunk-based development. The key constraint is that branches must be short-lived and merged frequently — daily at most. This is what Google, Facebook, and Microsoft practice at scale.

Trunk-Based Development and Autonomous Code Governance

Hydra is designed to work within trunk-based development workflows. Automated remediation pull requests from Hydra follow the same short-lived branch pattern: created, tested, and merged quickly. Because the trunk is always releasable, Hydra's automated fixes can ship to production as part of the next continuous deployment cycle without waiting for a release window.

Frequently Asked Questions

Does trunk-based development require continuous deployment?

No. Trunk-based development is a branching strategy. Teams can use it with any release model. However, it is a prerequisite for Continuous Integration and strongly enables Continuous Delivery and Deployment.

How do you handle releases in trunk-based development?

Teams using continuous delivery cut a release branch from the trunk when they are ready to ship. Bug fixes for that release are committed to the trunk and cherry-picked to the release branch. The trunk keeps moving forward.

What is the difference between trunk-based development and GitHub Flow?

GitHub Flow is a simplified branching model using feature branches merged to main via pull requests. It is compatible with trunk-based development when feature branches are kept short-lived. It is incompatible when branches accumulate weeks of work.

Is trunk-based development only for experienced teams?

It requires discipline and strong automated testing, which takes investment to build. However, DORA research shows that teams that adopt it consistently outperform those that do not on delivery metrics, regardless of experience level.