County finance needs a stabilized cut of the tax portal for a quarterly hotfix window while feature work continues elsewhere. Which branching approach fits that need?
Select an answer to reveal the explanation.
Short Explanation
A release branch is like freezing the ballot layout for Election Night while designers keep sketching next year’s forms in another room. You stabilize the cut without parking all city feature work.
Full Explanation
County finance’s quarterly hotfix window needs a stabilized cut of the tax portal while unrelated feature work continues. Cutting a release branch provides that stabilization line: hotfixes and release candidates land on the release branch, while feature branches keep progressing toward a later integration. That separation reduces the risk of unfinished features contaminating the hotfix window.
Deleting all feature branches so only experimental commits remain on main is the opposite of stabilization and destroys in-flight work. Rebasing every historical tag onto a single orphan commit nightly rewrites history destructively and does not create a controlled release line. Disabling branching and emailing zip archives abandons reviewable version control for a municipal financial system.
Exam caveat: release branches are for stabilization and hotfixes around a cut; long-lived release branches still need clear merge-back policies for critical fixes. Operational check: branch release/x.y from the intended commit, protect it, merge only approved hotfixes, tag the release, and keep feature work on separate branches merging to main per team policy. For county finance, the release branch also gives change-advisory boards a concrete artifact to approve for the quarterly window—feature work stays visible elsewhere without blocking the hotfix cut. Merge policy should state which fixes cherry-pick back to main after the window closes.