A city parking-meter integration engineer experiments with a local Git commit that was never pushed. Overnight they realize the experiment should not stay in history. Separately, a shared branch already has a bad commit that three other civic apps have pulled. Which actions match those two situations?

Git history repair depends on whether anyone else already has the commit. For a local-only experiment that was never pushed, rewriting the tip with reset (soft, mixed, or hard, as appropriate) removes that work from the branch without creating a public correction commit. For a bad commit already pulled by three other civic apps, rewriting shared history with reset would force every consumer to re-sync and risk losing their own work; a revert creates a new forward commit that undoes the change while leaving the prior history intact for everyone who already built on it.

Using revert for the unpushed experiment and reset for the published bad commit inverts the rule: revert is unnecessary noise on private history, and reset on a shared branch is the destructive rewrite others cannot safely absorb. Cherry-picking both histories onto a quarantine branch does not remove the bad commit from the shared branch others already pulled; it only copies patches elsewhere. Rebase --onto for a local experiment can reshape unpublished commits, but stash for a published bad commit merely shelves working-tree state and never undoes a commit already on the remote tip.

Exam caveat: once history is shared, prefer revert (or a carefully coordinated rewrite with force-push policy and teammate agreement)—never assume reset is always safer because it is quieter. Operational check: before reset, confirm the commit is absent from remotes with git status / git log @{u}; before revert on the shared branch, confirm the bad SHA with git log and that dependent civic apps can pull the revert commit cleanly.