Why GitFlow Fits an Enterprise That Needs Hotfixes Propagated Everywhere
You are designing a Git branching strategy for a large enterprise with multiple Azure DevOps projects. The strategy must support hotfixes for production releases, feature development in isolated branches, and release branches for stabilization. The team uses CI/CD pipelines that trigger on branch creation. You need to minimize merge conflicts and ensure that hotfix changes are propagated to all active branches. Which branching model should you recommend and how should you configure branch policies?
Quick Answer
GitFlow is the model built for this exact mix of requirements — dedicated hotfix branches that merge into both main and develop so a production fix reaches every active branch, plus release branches for stabilization and feature branches for isolated work. Pairing it with branch policies on main and develop requiring reviewers covers the propagation and quality requirements together.
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 GitFlow with main, develop, and hotfix branches. Configure branch policies on main and develop to enforce pull requests with required reviewers. Use a pipeline to automatically merge hotfix branches into both main and develop.
(GitFlow) is the correct recommendation because it provides dedicated hotfix branches that can be merged into both main and develop, ensuring hotfix changes are propagated to all active branches. GitFlow also supports feature branches, release branches for stabilization, and minimizes merge conflicts by isolating work. Branch policies on main and develop enforce pull requests with required reviewers, and a pipeline can automate merging hotfixes into both branches. Option A (GitHub Flow) lacks dedicated hotfix branches and release branches, making hotfix propagation difficult. Option B (trunk-based) relies on feature toggles and does not isolate hotfixes, increasing risk. Option C (forking) is designed for external contributions, not internal enterprise collaboration, and does not inherently handle hotfix propagation.
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 GitHub Flow with feature branches merging directly to main. Use a release branch for stabilization. Use pull requests for all merges.
Why it's wrong here
No separate hotfix branch; hotfixes would go to main and not propagate to release.
- ✗
Use trunk-based development with short-lived feature branches. Use feature toggles for incomplete work. No separate hotfix branch.
Why it's wrong here
Hotfixes need immediate deployment without feature toggles.
- ✗
Use a forking workflow where each developer forks the repository and submits pull requests. Use branch policies on the upstream main branch.
Why it's wrong here
Forking adds complexity for enterprise and does not address hotfix propagation.
- ✓
Use GitFlow with main, develop, and hotfix branches. Configure branch policies on main and develop to enforce pull requests with required reviewers. Use a pipeline to automatically merge hotfix branches into both main and develop.
Why this is correct
GitFlow supports hotfix propagation; policies enforce quality.
Visual reference
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
Feature
A feature is a distinct unit of functionality that delivers value to the user, often managed and tracked throughout the software development lifecycle.
About these practice questions
This AZ-400 question is part of Courseiva's 823-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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. Which THREE are common Git branching strategies used by development teams? (Select THREE.)
easy- ✓ A.GitFlow
- ✓ B.Trunk-based development
- ✓ C.Feature branching
- D.Monorepo
- E.Centralized version control
Why A: GitFlow is a common branching strategy that uses a main branch (master/main) alongside develop, feature, release, and hotfix branches. It provides a structured model for managing releases, hotfixes, and parallel development, making it suitable for projects with scheduled release cycles.
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.