Courseiva

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 development merges short-lived branches straight to main, so no release branch exists to stabilise a release candidate or isolate hotfixes from ongoing feature work. It suits teams with strong automated testing and continuous deployment, where release candidates are unnecessary.

  • ✗

    Use a forking workflow where each developer forks the repository and creates pull requests.

    Why it's wrong here

    A forking workflow isolates contributors from the shared repository and centres on pull requests, offering no release-candidate stabilisation branch or hotfix path. Forking is tempting for open-source or untrusted-contributor scenarios where write access must be restricted, but it does not structure feature, release and hotfix branches within one team's repository.

  • ✓

    Use Git Flow with feature, develop, release, and main branches.

    Why this is correct

    Git Flow's dedicated release branch lets the team stabilise a release candidate while develop continues accepting feature work, and main plus hotfix branches handle urgent production fixes. This matches the stem's feature, hotfix, and stabilisation requirements.

  • ✗

    Use GitHub Flow with feature branches and pull requests directly to main.

    Why it's wrong here

    GitHub Flow sends feature branches directly to main via pull requests, providing no release branch to freeze and stabilise a release candidate, and no defined hotfix path. It fits continuously deployed products where every merge ships immediately.

About these practice questions

Courseiva writes every AZ-400 question from scratch — 696 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 →

How Courseiva writes practice questions · Editorial policy

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: Option B is correct because release branches let you stabilize and harden a release (final testing, version bumps, minor fixes) in isolation while main continues to receive new work, which is essential for continuous delivery. Option C is correct because keeping main always in a deployable state is the core invariant of a CD-oriented branching strategy, enabling any commit on main to be released at any time. Option E is correct because hotfix branches must be cut from main (the production-ready line), fixed, then merged back into main for immediate release and also merged into develop so the fix is not lost in ongoing development. Option A is wrong because long-lived feature branches cause merge conflicts and delay integration, contradicting continuous delivery's need for short-lived branches and frequent merges. Option D is wrong because merging hotfixes directly into develop and cherry-picking to main inverts the correct flow and risks divergence, since the hotfix should originate from main and be propagated to both main and develop.

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.