A parks department developer is fixing a reservation bug and must keep work isolated until peer review. What source-control practice should they follow?
Select an answer to reveal the explanation.
Short Explanation
You can treat a feature branch like a side street off Main: fix the pothole there, then get it inspected before merging. Peer review gives you a chance to catch problems before the change reaches the protected main line.
Full Explanation
The reservation fix should remain isolated from the protected main line until peer review is complete. Creating a feature branch from main, committing the fix there, and opening a merge or pull request is standard source-control practice: it keeps main as the known-good integration branch, provides a reviewable diff, and supports CI checks before merging. Committing directly to a production tag bypasses branch-based review and protection; tags are markers, not substitutes for working branches. Force-pushing rewritten history onto main during business hours can disrupt other developers’ clones and violate typical municipal change controls. Keeping the only copy on an encrypted USB drive is not source control and removes collaboration, remote backup, and auditable history. Exam caveat: protected main with PR/MR review is the expected pattern even for small fixes, unless a documented emergency break-glass process applies. Practical check: create a feature branch from updated main, commit and push the fix, open the MR, and confirm required reviewers and pipeline checks before merge. In a parks system, review also helps catch edge cases before a reservation bug affects citizens during seasonal peak traffic.