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.
⚠ Common exam trap
AZ-400 often tests the misconception that trunk-based development is always best, but for complex release management, GitFlow with hotfix propagation is required.
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 designed for projects with multiple release cycles and hotfixes. It uses main, develop, feature, release, and hotfix branches. Configuring branch policies on main and develop enforces pull requests with required reviewers, ensuring code quality. Automatically merging hotfix branches into both main and develop ensures that hotfix changes are propagated to all active branches, minimizing merge conflicts and ensuring consistency.
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
GitHub Flow merges features straight to main with no develop or release lineage, so hotfixes cannot be propagated systematically to active release branches. It suits small teams shipping continuously from a single production branch, not enterprises needing parallel release stabilisation.
- ✗
Use trunk-based development with short-lived feature branches. Use feature toggles for incomplete work. No separate hotfix branch.
Why it's wrong here
Trunk-based development removes the release branch the stem requires for stabilisation, and feature toggles cannot propagate a hotfix to already-shipped releases. Trunk-based suits teams releasing continuously from main with high test automation and no parallel supported versions.
- ✗
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 isolates contributors from the upstream repository, so hotfix commits never reach the release or feature branches without manual synchronisation, defeating the propagation requirement. Forking suits open-source projects with untrusted contributors, where maintainers gate pull requests into a single canonical branch.
- ✓
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's dedicated hotfix branches, created from main and merged back into both main and develop, satisfy the requirement that hotfix changes propagate to all active branches. Branch policies on main and develop enforce pull requests with required reviewers, minimising conflicts during stabilisation.
Visual reference
Go deeper
Related to this question
Learn chapter
Managing Build Quality and Package Dependencies
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
Azure DevOps
Azure DevOps is a Microsoft service that provides development tools for planning, building, testing, and deploying software applications using automated pipelines and collaboration features.
About these practice questions
This AZ-400 question is part of Courseiva's 696-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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Microsoft exam blueprint
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.