Undo Mechanics: Reset, Revert, Restore

Git has three different commands for "undo" and they are not interchangeable. Choosing the wrong one in front of a colleague is embarrassing; choosing the wrong one on a shared branch is an incident.

Why This Module Matters

"Undo the last change" is one sentence in English and at least four different operations in Git. Do you mean: discard an edit you have not committed? Un-stage something you added? Move the branch pointer back and pretend the last three commits never happened? Or publish a new commit that reverses a change everyone already has?

The single question that sorts them all out is: has anyone else seen this commit?

If yes, the only safe answer is git revert. It undoes the change by adding history rather than editing it, so everyone's clone stays consistent. If no, git reset is available in three depths, and knowing which depth keeps your work is the difference between a clean redo and a lost afternoon.

git restore is the newest of the three and exists to take the file-level jobs away from checkout and reset, which were badly overloaded. Once you see the split, the whole area stops feeling arbitrary.

What You'll Learn

• git revert: undoing published commits safely, including reverting a merge with -m
• The three resets, in one sentence each: --soft keeps everything staged, --mixed keeps it in the working directory, --hard deletes it
• What git reset --hard actually destroys — and what the reflog can still get back
• git restore for files and git restore --staged for un-staging, and how they map onto old checkout / reset habits
• A decision path you can follow under pressure without thinking it through from first principles

Pro Tip

Run git status before and after every undo command. It is two seconds, and it is how you catch the case where you undid something adjacent to what you meant.