A team currently uses GitFlow with develop, feature, release, and hotfix branches, but its delivery goal is continuous delivery with small, frequent production releases. They find that work sits on the develop branch for weeks and that release branches cause painful late integration. Which change to the branching model most directly supports their continuous delivery goal?
- AKeep GitFlow but shorten each release branch lifetime to a single day, merging release branches into both develop and main as soon as the nightly stabilisation build passes.
- BReplace the central repository with a forking workflow so each developer integrates on their own fork first, reducing churn on the shared develop branch before promotion.
- CMove to trunk-based development with short-lived branches merged to main daily, releasing directly from main and using feature flags to hide work that is not yet ready. Correct
- DAdopt a release branch per environment, promoting commits through dev, test, and production branches in sequence so each environment has its own stable long-lived line.
Why A is wrong: Compressing GitFlow timings is tempting, but the develop branch and dual-merge ceremony remain, so late integration and weeks-long develop divergence are only partly reduced, not removed.
Why B is wrong: A forking workflow adds cross-fork integration steps for an internal team and does nothing to shorten the long-lived develop branch, so it works against frequent shared releases.
Why C is correct: Trunk-based development with short branches and feature flags removes the long-lived develop and release branches, enabling the small, frequent, low-integration-pain releases continuous delivery requires.
Why D is wrong: Per-environment long-lived branches multiply the very long-lived branches causing late integration pain, so this increases divergence rather than enabling continuous delivery.