A municipal platform engineer finishes local edits to 311 bot playbooks and wants those changes recorded in Git before anyone else reviews them. Which local sequence is correct?
Select an answer to reveal the explanation.
Short Explanation
Local Git is like putting forms in the outbox before the courier shows up. You stage with add, then stamp the record with commit — push comes later when you are ready to share with the city team.
Full Explanation
When a municipal platform engineer finishes local edits to 311 bot playbooks, Git must record those changes on the laptop before remote collaboration. The correct local sequence is to stage the modified files with git add (updating the index) and then create a local commit with git commit. That snapshot captures intent, enables reviewable history, and leaves push as a later sharing step rather than a prerequisite for recording work.
Pushing immediately to the remote before staging reverses the lifecycle and can publish incomplete or unindexed work—or fail because nothing was committed. Deleting the working tree and re-cloning does not invent meaningful commits of the engineer’s edits; it discards local changes. Running git fetch alone updates remote-tracking refs; it neither stages nor commits pending playbook modifications.
Exam caveat: commit is local; push is remote publication. Questions that mention “before anyone else reviews” point at the local add/commit pair, not at merge-request mechanics. Operational check: after editing, run git status to see changes, git add the paths, git commit with a ticket-oriented message, then confirm git status is clean for those files while git log -1 shows the new commit still unpushed if desired.