After committing locally, a city developer needs the shared team repository to receive those commits so colleagues can pull the latest work. Which source-control action accomplishes that?
Select an answer to reveal the explanation.
Short Explanation
Commit is local; push is ‘send it to the shared fridge.’ Until you push, the rest of the city team still sees yesterday’s leftovers. Remotes exist so nobody’s laptop is the single source of truth.
Full Explanation
After committing locally, a city developer needs the shared team repository to receive those commits so colleagues can pull the latest work; the action that accomplishes that is a code push that uploads local commits to the shared remote repository. Municipal teams depend on remotes for shared visibility, off-laptop durability of history, and CI triggers—until a push occurs, collaborators still see yesterday's tree. Rebasing does not permanently delete the remote so only laptops hold history; that misstates both rebase behavior and why remotes exist. Squashing commits does not replace the need for any remote hosting service. Tagging alone does not publish binaries to every production cluster; tags mark revisions while artifact publishing and deployment remain separate pipeline steps. Exam caveat: distinguish commit (local snapshot), push (update remote), fetch/pull (retrieve), and merge (integrate branches)—Cloud+ items frequently test that vocabulary sequence in DevOps questions. Operational check: push to the agreed remote and branch, confirm another engineer can fetch the new commit, verify CI started if branch rules trigger on push, avoid force-push to shared civic branches without agreement, and document the canonical remote URL in the project README.