The transit authority’s cloud team insists new fare-calculator features be developed on short-lived branches instead of committing straight to production main. Why does branch management matter?
Select an answer to reveal the explanation.
Short Explanation
Branches are sandboxes with labels. Build the fare-calculator experiment off to the side so main—the thing that can ship—stays stable. When the work is ready, review and merge; don’t treat production main like a scratch pad.
Full Explanation
The transit authority's cloud team insisting that new fare-calculator features be developed on short-lived branches instead of committing straight to production main is correct because branches isolate work in progress so unstable changes do not land directly on production main. Branch management lets municipal engineers experiment, review, and test without destabilizing the shared production line citizens depend on. Branches do not permanently disable continuous integration for every repository; CI typically runs on branch pushes and pull requests. Branches do not replace the need for access control on cloud consoles—identity and IAM remain separate. Branches do not force all engineers to share a single laptop working copy; distributed clones remain independent. Exam caveat: long-lived divergent branches create merge pain; prefer short-lived feature branches with frequent integration into main under civic branching policy. Operational check: create a feature branch from main, commit fare-calculator work there, open a pull request with CI, merge only after review, delete the short-lived branch, and confirm production main never received direct unreviewed commits during the change window.