Match each Git branching strategy to its description.
Drag a concept onto its matching description — or click a concept then click the description.
Uses develop and feature branches with release branches
Feature branches merged to main with pull requests
Short-lived branches merged frequently to main
Main branch with release branches for production
Answer choices
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
Git Flow: Uses develop and master branches with release branches.
Git branching strategies vary in complexity. Git Flow uses long-lived branches (develop, release), GitHub Flow is simple with feature branches to main, GitLab Flow adds environment branches, and trunk-based development centers on frequent commits to main. Common confusions involve swapping descriptions between Git Flow and GitHub Flow.
Answer analysis
For each option: why learners choose it and why it is or isn't the right answer here.
Git Flow: Uses develop and master branches with release branches.
Why this is correct
Git Flow is a heavyweight branching model that maintains two long-lived branches: master (or main) holds production-ready code, while develop serves as an integration branch for ongoing work. Feature branches are cut from develop, and when a release is imminent, a release branch is created from develop to stabilize the code, apply version bumps, and fix release-specific bugs before merging to both master and develop. Hotfix branches also branch off master for urgent production issues and are merged back into master and develop, ensuring the parallel tracks remain synchronized.
GitHub Flow: Simple model with feature branches and pull requests to main.
Why this is correct
GitHub Flow is an intentionally simple workflow built around a single main branch that is always in a deployable state. Developers create short-lived feature branches from main, commit to them, open a pull request for code review and automated checks, and merge directly back into main, after which the code is immediately deployed. This model eliminates long-lived develop or release branches, favoring continuous delivery and rapid iteration over rigid branch structure, making it ideal for teams with strong automated testing and deployment pipelines.
GitLab Flow: Similar to GitHub Flow but with environment branches.
Why this is correct
GitLab Flow is a more structured variant of GitHub Flow designed for scenarios that require staged or multi-environment deployments. It adds persistent environment branches such as staging and production, alongside feature branches that merge into main via merge requests. Deployment to each environment is triggered by merging into the corresponding environment branch, providing a clear, auditable promotion path from development to staging to production while retaining the lightweight pull-request workflow of GitHub Flow.
Trunk-based development: Frequent commits to main, short-lived branches.
Why this is correct
Trunk-based development is a source-control practice that prioritizes frequent integration into a single shared trunk (main) over long-lived isolation. Developers commit small, incremental changes directly to main, or use very short-lived feature branches that last only hours or a few days, rather than weeks. This approach relies heavily on comprehensive automated testing and feature flags to keep main releasable at all times, minimizing merge conflicts and enabling continuous integration and continuous delivery at scale.
Git Flow: Uses only main branch and feature branches.
Why it's wrong here
This is incorrect; Git Flow is characterized by multiple long-lived branches, including develop, feature, release, and hotfix branches, not just main and feature. This description more accurately matches GitHub Flow's simple model where feature branches merge directly into main via pull requests.
GitHub Flow: Uses develop and release branches.
Why it's wrong here
This is incorrect; GitHub Flow is a minimal workflow with a single main branch and short-lived feature branches merged via pull requests, without long-lived develop or release branches. The presence of develop and release branches is a hallmark of Git Flow, which uses them to manage integration and production releases.
Visual reference
Go deeper
Learn chapter
Source Control Strategy Design
Key term
Environment
An environment is a dedicated set of computing resources, configurations, and services used to develop, test, or host software applications in a controlled and repeatable way.
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
One of 823 original AZ-400 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
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.