Trunk-Based Development

To deliver faster, teams must work in a way that reduces friction and promotes flow. A good branching strategy should be simple to understand and implement and should enable:

• the team to move fast with sufficient quality
• members to function harmoniously without conflicts
• smooth flow by removing bottlenecks and unnecessary overhead
• faster feedback for better iterative development
• continuous delivery for release candidates

Continuous delivery practices small-batch work with frequent merges to the main branch. This trunk-based development approach enables continuous integration and provides fast feedback. In this model, the approach to branching is simple, with an emphasis on integrating code to trunk as fast as possible to produce production release candidate.

main branch is the one, long-lived branch the represents the application. All commits on this branch should have successful builds and should be releasable at any moment. When working in a continuous delivery model, the team must agree to respect and protect main, and swarm when it fails.

What about releases branches? Release branches are generally discouraged in continous delivery and should only happen if your organization does not support releasing on-demand. However, if parallel development must occur while the team prepares for a release, a short-lived branch can be cut for testing and bugfixes, and then removed once the team completes the release.

Working Branches: short-lived, merge often

With working branches, commits are made on branches off main and merged in through a pull request after a successful CI build validation. Following TBE principals, all development should correspond to tickets and integrated with an issue tracking software. Working branches should be short-lived (less than 1 day), exist for a single unit of work, and removed after merging into main.

Pure Trunk-Based Development

For product teams with mature development practices, short-lived working branches can be omitted in favor of direct commits to main. Before moving to pure trunk-based development, there are some caveats that should be considered to reduce friction and promote stability:

• Build validation comes locally through Git hooks (e.g. pre-commit or pre-push) instead of a branch build from the CI server.
• Peer reviews come from structured pair programming instead of pull requests.

Gitflow: a branching pattern that does not support continuous delivery. Gitflow is an older branching pattern that was created to support releases mandated by an enterprise release schedule (monthly for example). The infrequent release pattern creates the need to hotfix and address severe/critical defects in production. This complex branching pattern adds overhead and produces large-batch work with multiple handoffs. With the move to continuous delivery, product teams should deploy often and frequently to production and focus on failing foward.