200-901 Software Development and Design Practice Question
Which Git branching strategy typically involves a long-lived 'develop' branch where feature branches are merged, and releases are created from a 'release' branch?
⚠ Common exam trap
Cisco often tests the distinction between GitFlow's multiple long-lived branches (develop, release, main) and simpler workflows like GitHub Flow or trunk-based development, where candidates mistakenly assume any workflow with feature branches is GitFlow.
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
✓
GitFlow
GitFlow is correct because it defines a long-lived 'develop' branch for integrating feature branches, and a separate 'release' branch for preparing releases. This strategy uses dedicated branches for features, releases, and hotfixes, with strict merging rules back to 'develop' and 'main'.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
GitFlow
Why this is correct
GitFlow defines a long-lived develop branch that accumulates merged feature branches, with release branches cut from develop for stabilisation before merging into main. This matches the stem's described structure precisely, unlike trunk-based or GitHub Flow.
- ✗
GitHub Flow
Why it's wrong here
GitHub Flow lacks a dedicated long-lived `develop` branch and a separate `release` branch; instead, all feature branches merge directly into `main`, and releases are cut from `main` itself. This fails the scenario because the question explicitly requires a persistent `develop` branch for integration and a distinct `release` branch for stabilisation. It is tempting because GitHub Flow is a widely taught, lightweight strategy for continuous deployment, and it would be the correct choice for a team practising trunk‑based development with frequent, small releases directly from `main`.
- ✗
Trunk-based development
Why it's wrong here
Trunk-based development keeps everyone committing to a single mainline with short-lived branches and feature flags, deliberately avoiding long-lived develop and release branches. It is tempting because it enables continuous integration, but the described develop-plus-release structure is Gitflow, not trunk-based.
- ✗
Feature branch workflow
Why it's wrong here
Feature branch workflow isolates each feature on its own short-lived branch merged back to a shared mainline; it defines no long-lived develop or release branches. It suits small teams wanting review isolation, but the develop-and-release topology described belongs to Gitflow.
About these practice questions
Courseiva writes every 200-901 question from scratch — 975 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 →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 200-901 practice question is part of Courseiva's free Cisco 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 200-901 exam.