L4. Branching Strategies: Trunk-Based, Feature Branch & Release Branch
Trunk-based development with feature flags drives the highest deployment frequency, but feature branches and release branches still have their place: know when each strategy fits.
Trunk-Based Development: Continuous Integration at Its Core
Trunk-based development is the branching strategy most strongly correlated with high deployment frequency and elite-performing teams. Instead of long-lived feature branches, developers commit small, frequent changes directly to a single trunk (or main) branch, or to short-lived branches (hours, not weeks) that merge back quickly.
The key insight is this: instead of hiding incomplete work behind a long-lived branch, trunk-based development uses feature flags (runtime conditionals) to hide unfinished features from users. A feature flag lets code merge to main even if the feature isn't complete yet, because the flag keeps it disabled in production.
The benefit is significant. Merging small changes frequently means merge conflicts are small and resolution is fast. Large merge conflicts happen when branches diverge for weeks; trunk-based development eliminates that risk by integrating constantly.
Feature Branch Workflow
Feature branch development assigns each change (feature, bugfix) to its own branch off main. The branch lives as long as the feature takes, then a pull request brings it back to main after review and testing.
This works well for teams still building strong testing and CI practices. The branch is a safe place to develop without affecting main. But the longer a branch lives, the higher the risk of merge conflicts. If three developers each have a feature branch living for two weeks, by the time they merge, each one might have significant conflicts to resolve.
Feature branches suit teams practicing shorter, focused development cycles where most branches merge within days, not weeks.
Release Branch Strategy
A release branch is cut from main at release time. This branch receives only stabilization and hotfixes; development of new features continues on main. After the release, the hotfixes are merged back to main.
This strategy is essential for software shipped in distinct releases: packaged on-premises software, mobile apps requiring app-store review cycles, or any product versioned with major.minor.patch releases.
Choosing Your Strategy
| Strategy | Deployment Frequency | Best For | Trade-Off |
|---|---|---|---|
| Trunk-Based | Multiple per day | High-velocity delivery | Requires strong testing and feature flags |
| Feature Branch | Once per week or less | Teams building CI discipline | Higher merge conflict risk as branches age |
| Release Branch | Monthly or quarterly | Packaged/on-premises software | Parallel maintenance of multiple branches |
Common Misunderstanding: "Trunk-Based Means Zero Branches"
This is false. Trunk-based development does not prohibit branches. It prohibits long-lived branches. A branch that lives for a few hours or a day before merging is consistent with trunk-based development. The exam tests this distinction carefully: if you see a question saying "trunk-based development requires developers to commit directly with no branches," that is a trap answer. Exam tip: The AZ-400 exam emphasizes that trunk-based development correlates with the highest deployment frequency specifically because small, frequent integrations minimize merge risk and conflict resolution time. Know when each strategy fits your team's delivery model, and remember that trunk-based development is not the same as having no branches at all.
- ✓Trunk-based development uses small, frequent commits to a single trunk with only short-lived branches, relying on feature flags to hide incomplete work rather than long-lived feature branches
- ✓Feature branch workflows isolate each change on its own branch merged via pull request, but the longer a branch lives the higher the risk of a large, conflict-prone merge
- ✓A release branch is cut from main at release time to stabilize and apply hotfixes without blocking new feature work continuing to merge into main
- ✓Trunk-based development is the branching model most associated with elite-performing teams' high deployment frequency, precisely because small integrations minimize merge conflict risk
- ✓Trunk-based development does not mean zero branching, it means avoiding long-lived branches; short-lived branches merged within hours or a day are still consistent with the model
1. A team wants to increase deployment frequency and reduce the pain of large merge conflicts. Which branching strategy, combined with feature flags, best supports this goal?
2. A company ships a packaged on-premises application with quarterly version releases. Which branching approach best fits stabilizing a specific version while development continues?
3. Which statement correctly describes trunk-based development?
Recommended: Pluralsight
This free course covers the theory. Pluralsight adds structured DevOps Engineer Expert learning paths, hands-on Azure Pipelines and GitHub Actions labs, and timed practice exams to make it stick before exam day.