A developer finishes a permitting-portal fix on a feature branch and wants discussion plus automated checks before the work joins main. Which collaboration mechanism fits?
Select an answer to reveal the explanation.
Short Explanation
A pull request is the polite knock on main’s door: here’s the diff, please review, and let CI kick the tires. Zipping code around or editing main on a jump box skips the conversation and the safety net. Municipal teams use PRs so fixes don’t sneak in dark.
Full Explanation
A developer who finishes a permitting-portal fix on a feature branch and wants discussion plus automated checks before the work joins main should open a pull request (merge request) for review and CI checks before merge. Pull requests package proposed branch changes for human conversation and continuous integration against the protected main line used by municipal delivery pipelines. Emailing a zip of the working directory to the whole department skips reproducible diffs, status checks, and a durable threaded discussion. Editing main directly on the jump host during lunch bypasses both peer review and automation gates. Posting only a screenshot of the IDE without the patch cannot be tested, commented line-by-line, or merged into a trustworthy history. Exam caveat: protected-branch rules should block direct pushes to main and require satisfying PR status checks—written process without technical enforcement fails under civic release deadlines. Operational check: open the PR against main, confirm required reviewers and CI jobs are green, merge through the platform, link the PR to the work item for the portal fix, verify the commit is on main, and only then promote downstream municipal environments.