Choosing Git Flow to Stabilize Releases Before Final Deployment
A development team is transitioning from a centralized version control system to Git in Azure Repos. The team lead wants to ensure that the branch structure supports both feature development and hotfix releases, with the ability to stabilize a release candidate before final deployment. Which branch strategy should the team implement?
Quick Answer
Git Flow's structured branch hierarchy — feature, develop, release, and main — is purpose-built for this exact combination: feature branches isolate new work, develop integrates it, release branches give you a dedicated place to stabilize a candidate before it ever reaches main, and hotfix branches handle urgent production fixes without disrupting the release cycle.
⚠ Common exam trap
Candidates often confuse GitHub Flow (option D) with Git Flow, but GitHub Flow lacks the dedicated release and hotfix branches needed for the described release stabilization and hotfix requirements.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use Git Flow with feature, develop, release, and main branches.
Git Flow is the correct choice because it explicitly supports feature development, release stabilization, and hotfix releases through its structured branch hierarchy. The release branch allows the team to stabilize a release candidate before merging to main, while hotfix branches can be created from main for urgent fixes. This aligns perfectly with the requirement for both feature development and hotfix releases with release candidate stabilization.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use trunk-based development with short-lived feature branches that merge directly to main.
Why it's wrong here
Trunk-based does not have release branches for stabilization.
- ✗
Use a forking workflow where each developer forks the repository and creates pull requests.
Why it's wrong here
Forking workflow is for external contributions, not internal release management.
- ✓
Use Git Flow with feature, develop, release, and main branches.
Why this is correct
Git Flow provides release branches for stabilization before merging to main.
- ✗
Use GitHub Flow with feature branches and pull requests directly to main.
Why it's wrong here
GitHub Flow lacks release branches for stabilization.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Git
Git is a version control system that tracks changes to files so multiple people can work on the same project without overwriting each other's work.
Key term
Branch
A branch is a pointer to a specific commit in a version control system that allows you to work on features or fixes in isolation from the main codebase.
About these practice questions
Courseiva writes every AZ-400 question from scratch — 823 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on AZ-400
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Your organization uses Azure Repos and wants to implement a Git branching strategy that supports continuous delivery with hotfix capabilities. Which THREE practices should be part of the strategy?
medium- A.Feature branches have long lifetimes and are merged to main only after full feature completion.
- ✓ B.Release branches are used to stabilize a release before merging to main.
- ✓ C.Main branch is always in a deployable state.
- D.Hotfixes are merged directly to develop and then cherry-picked to main.
- ✓ E.Hotfix branches are created from main and merged back into main and develop.
Why B: Release branches allow a team to stabilize a release candidate without disrupting ongoing development on the develop branch. Once the release is fully tested and stable, it is merged into main, ensuring that main always contains production-ready code. This aligns with the continuous delivery principle of maintaining a deployable main branch. Hotfix branches should be created from main to address urgent production issues, and the fix should be merged back into both main and develop to ensure the fix is not lost in subsequent development. This keeps main in a deployable state and avoids the risk of cherry-picking.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-400 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-400 exam.