Git branching strategies compared
A branching strategy is the team’s agreement on where work happens, how it reaches the main line and how releases are cut. The decision rule is simple: the more often you release one version, the shorter your branches should be; the more versions you must support at once, the more release branches you need. Everything else is detail on those two axes.
The four models side by side
| Model | Branches | Merge path | Release cadence it suits |
|---|---|---|---|
| Trunk-based | One shared trunk, plus very short-lived branches | Into trunk, at least daily, unfinished work behind feature flags | Many deployments per day, strong automated tests |
| GitHub flow | main plus one branch per change | Pull request, review, merge, delete branch | Continuous delivery of one live version |
| GitFlow | main, develop, feature/*, release/*, hotfix/* | Features into develop; releases and hotfixes into both main and develop | Scheduled, versioned releases |
| Release branches (as Microsoft describes them) | Feature branches plus a long-lived branch per supported release | Fixes land in the release branch and are cherry-picked back to main | Products with several shipped versions |
What each model actually does
Trunk-based development. Developers share a single branch, the trunk, and avoid long-lived development branches. The trunkbaseddevelopment.com site says team members should commit to the trunk at least once every 24 hours. Very small teams may commit straight to it; larger teams use short-lived branches with pull requests and a build server that catches breakage. Because half-finished work lands in the trunk, feature flags hide it until it is ready. Releases either come straight from the trunk with fixes rolled forward, or from a release branch cut just in time and deleted afterwards.
GitHub flow. Create a branch from the default branch, commit, open a pull request, address review comments, merge, delete the branch. GitHub’s documentation describes it as lightweight. Branch protection rules can block a merge until requirements are met. There is no develop branch and no release branch.
GitFlow. Described by Vincent Driessen in 2010. main (called master in the original article) holds released code, each release tagged. develop collects work for the next release. Feature branches come off develop. A release branch is cut from develop when it is ready, is limited to final fixes and version metadata, and merges into both main and develop. A hotfix branch comes off main and also merges into both. In a later note the author wrote that for continuously delivered web apps a simpler flow such as GitHub flow is better, and that GitFlow may still suit explicitly versioned software or software with several versions in the field. That is the model’s honest scope.
Release branches. Microsoft’s Azure Repos guidance builds on feature branches and pull requests, then adds a release branch cut from main close to a release. Bug fixes are made on short branches and merged into the release branch by pull request. The release branch is long lived and is not merged back; fixes are ported to main by cherry-picking, so release-specific changes do not leak into the main line. The page also notes the reverse route, used by the Azure DevOps team itself: fix in main first, then port the change to the release branch. Each active release branch is another version to support, so the guidance says to lock a branch once the release is out of support.
A worked example
A team of eight builds a web shop and deploys when a change is merged, about five times a day. They run unit tests on every pull request. GitHub flow or trunk-based development fits. A develop branch would only add a second place where code waits.
The same team also ships a desktop client, and customers run versions 4 and 5. A security fix must reach both. Here, release branches matter: the fix is made once, applied to the release 4 and release 5 branches, and cherry-picked to main. The two products can use different models in different repositories, and exams often hide that.
Which exams test this
| Exam | How the topic appears | Where covered on this site |
|---|---|---|
| AZ-400 | Design and implement a source control strategy (10–15%): design a branch strategy (trunk-based, feature branch, release branch) and enforce pull requests and merge restrictions with branch policies and branch protection rules. Processes and communications (10–15%) adds a flow-of-work structure including GitHub Flow | Source control explained and the processes and communications guide |
| DP-800 | Secure, optimize, and deploy database solutions (35–40%), outline as of October 19, 2026: manage branching, pull requests and conflict resolution for SQL Database Projects, with branching policies and code owners on deployment pipelines | Secure, optimize and deploy |
| DP-750 | Minor topic. Deploy and maintain data pipelines and workloads (30–35%): Git best practices and managing branches, pull requests and conflicts. Branch handling, not the choice between models | Deploy and maintain pipelines |
| Databricks Data Engineer Associate | Minor topic. Implementing CI/CD (10%): create and switch branches in Git folders, commit, push and open pull requests | Jobs and CI/CD |
| 200-901 | Minor topic. Software Development and Design (15%): use Git operations including branch, merge and handling conflicts. Git mechanics rather than strategy | Software development and design and study plan |
| N10-009 | Minor topic. Networking Concepts (23%): branching is listed under source control for infrastructure as code | N10-009 networking concepts explained |
Only AZ-400 asks for a branching strategy to be designed; the other exams test working with branches and pull requests.
How the questions are built
Stems give a team size, a release cadence and a problem, then ask for the strategy or the control. Words that decide the answer:
- “Deploy multiple times a day”, “short-lived”, “feature flags” point to trunk-based development.
- “Maintain several versions”, “support older releases”, “hotfix to a shipped version” point to release branches.
- “Enforce review before merge”, “prevent direct pushes” is not a strategy question. It is a branch policy in Azure Repos or a branch protection rule in GitHub, and the exam mixes the two vocabularies deliberately.
- “Integration problems from long-lived branches” points back to shorter branches and more frequent merging.
The classic trap is choosing GitFlow because it looks the most complete. For a team that releases continuously, the extra branches are overhead. Another is a fix applied to a release branch only, so main regresses in the next release.
Question 1. A team of ten deploys a web application to production several times a day. Long-running feature branches have caused painful merges, and unfinished features sometimes need to be merged before they are ready for users. Which approach addresses both problems?
- A. Create a release branch for every sprint
- B. Adopt GitFlow with a long-lived develop branch
- C. Keep feature branches and squash merge them every two weeks
- D. Use trunk-based development with feature flags
Show answer
Answer: D
Trunk-based development keeps branches short and merges to the trunk at least daily, which removes the painful merges, and feature flags keep unfinished work hidden from users. A release branch per sprint adds long-lived branches and does not stop late merges. GitFlow adds develop and release branches, which suits scheduled versioned releases. Merging with squash changes the history format but not how long work stays unmerged.
Question 2. A vendor ships a product in which customers run versions 3 and 4. A critical security fix must reach both versions, and the fix must also be in the next version built from the main branch. What is the recommended way to apply it?
- A. Apply the fix to each supported release branch and cherry-pick it into main
- B. Fix main only and tell customers to upgrade
- C. Merge the release 3 branch into release 4 and then into main
- D. Create a tag on the vulnerable commit
Show answer
Answer: A
Release branches exist for this case. The fix is applied to each supported release branch and cherry-picked into main through a feature branch and pull request, so it is not lost in the next version. Merging release branches into main can bring release-specific changes along. Tagging does not change any branch content. Fixing only main leaves the shipped versions vulnerable.
Go deeper
- Git branching guidance, Microsoft’s feature-branch and release-branch recommendations.
- GitHub flow, the six steps and where branch protection fits.
- Trunk Based Development, the reference site for the model.
- A successful Git branching model, the original GitFlow article with its author’s later note.
- On this site: CI/CD explained for what runs after the merge, and the AZ-400 cheat sheet.