A five-person startup with little Git experience wants a branching model that is quick to learn, still requires peer review of changes, and fits a continuous deployment pipeline. Which model should it choose?
Show answer and explanation
Answer: D
A short-lived topic branch model, often called GitHub Flow, is simple: create a branch, commit, open a pull request, review, and merge into main once automated checks pass. It delivers peer review and CI integration with only one long-lived branch to understand. Layered models like GitFlow add several branch types with different merge rules, which slows a newcomer. Direct commits to main skip review, and long-lived parallel release branches add merge overhead that a small team does not need.
Why the other options are wrong
- A. GitFlow-style layering adds branch types and merge rules that a newcomer must master before shipping. The added structure suits scheduled releases more than continuous deployment.
- B. Committing directly to the production branch removes review, the main quality checkpoint this team wants. Mistakes then reach users without a second pair of eyes.
- C. Parallel long-lived release branches create merge and synchronization work across branches. That complexity is unnecessary for a single product deployed continuously.