Undoing mistakes: reset, revert & restore

The key is remembering the three places your work lives — the working directory (your files), the staging area, and committed history — because each command operates on different ones.

git restore — throw away uncommitted changes

git restore is the newest and most focused: it undoes changes in your working directory and staging area. It doesn't touch commit history at all, which makes it the safe one for "I haven't committed yet, I just want to undo."

Discard edits to a file (revert it to the last committed version — this destroys those edits, so be sure):

git restore Program.cs

Unstage a file you added but haven't committed (keeps your edits, just takes it out of the staging area):

git restore --staged Program.cs

Those two cover the everyday "oops" before a commit: dump a change you don't want, or back a file out of the next commit.

git revert — safely undo a commit that's already shared

git revert undoes a commit by creating a new commit that applies the opposite changes. The original stays in history; you're adding an "undo" on top. That sounds roundabout, but it's exactly what you want when the commit has already been pushed and others may have it:

git revert a1b2c3d

Because it only adds to history rather than rewriting it, revert is safe on shared branches. Nobody's existing history breaks; they just pull your new "undo this" commit like any other change. This is the right tool for "we shipped a bad commit to main and need to back it out cleanly."

git reset — move the branch backward (powerful, sharp)

git reset moves your branch pointer back to an earlier commit, effectively rewinding history. It's the most powerful and the easiest to hurt yourself with. It has three modes, and the difference is what happens to the changes from the commits you're rewinding past.

Undo the last commit but keep the changes staged (--soft) — perfect for "I committed too early" or "my message was wrong, let me redo it":

git reset --soft HEAD~1

Undo the last commit and unstage the changes, but keep them in your files (--mixed, the default) — you keep the work, but back to square one before staging:

git reset HEAD~1

Undo the last commit and throw the changes away entirely (--hard) — this deletes the work. Use it only when you're certain you want those changes gone:

git reset --hard HEAD~1

HEAD~1 means "one commit back"; HEAD~2 is two, and so on.

A quick decision guide

• Haven't committed, want to drop a change or unstage a file? → git restore (or git restore --staged).
• Committed locally, not pushed, want to redo it? → git reset (--soft to keep and re-commit, --hard only if you want the work gone).
• Already pushed, need to back a commit out safely? → git revert.

The safety net: reflog

One reassurance that makes all of this less scary: git almost never truly loses committed work, even after a reset --hard. There's a log of everywhere your branch has pointed, the reflog:

git reflog

It lists recent positions of HEAD with their hashes, so if you reset too far you can usually find the commit you "lost" and get back to it with git reset --hard <that hash>. It's saved more panicked afternoons than almost any other command — worth knowing it exists before you need it.

Get the three undo commands straight — restore for uncommitted, reset for local commits, revert for shared ones — and "I made a mistake" stops being a crisis and becomes a thirty-second fix.