How to Undo Anything in Git (The Real Superpower)

Part 2 of the “Git & Version Control Mastery” series. The fear of Git comes from one belief: that you can break something permanently. You almost never can.

Watch a developer who’s scared of Git and you’ll see the same pattern: they avoid commands they don’t fully understand, they make duplicate backup folders “just in case,” and when something goes wrong they freeze, terrified they’ve lost work forever. The fear is real, but the premise is mostly false. Git is built to let you undo things — once you know the handful of commands for each situation, that fear evaporates and you start moving boldly.

The trick is that “undo” isn’t one command — it depends on where the thing you want to undo is. Let me give you the map, situation by situation.

Git almost never truly deletes your work. Committed work especially is incredibly hard to lose. Most “I destroyed everything” moments are one recovery command away — if you know which one.

First: Understand the Three Places

Every change in Git lives in one of three areas, and “undo” means something different in each:

Working directory  →  Staging area (index)  →  Repository (commits)
   (edited files)        (git add'ed)            (git commit'ed)

Knowing which area your mistake is in tells you which command fixes it.

Undo #1: Discard Uncommitted Changes

You edited a file and want to throw the changes away (back to the last commit):

git restore <file>          # discard changes in one file (modern)
git restore .               # discard ALL unstaged changes
git checkout -- <file>      # older syntax, same effect

Be careful: this does permanently discard uncommitted edits (they were never saved). It’s the one place Git can actually lose work — which is itself a reason to commit early and often.

Undo #2: Unstage Something You git added

You staged a file you didn’t mean to, but you want to keep the changes:

git restore --staged <file>    # unstage, keep the edits (modern)
git reset HEAD <file>          # older syntax, same effect

This just moves the change back from “staged” to “modified” — nothing is lost.

Undo #3: Fix the Last Commit

Committed too early, forgot a file, or wrote a bad message:

git commit --amend                       # change the last commit (message and/or staged files)
git commit --amend --no-edit             # add staged changes, keep the message

--amend replaces the last commit. Safe on local commits; avoid it on commits you've already pushed (it rewrites history — see Part 1).

Undo #4: Undo a Commit (Two Very Different Ways)

This is where people get scared, because there are two tools and they do opposite things:

# revert: creates a NEW commit that undoes an old one. Safe for shared history.
git revert <commit>        # the undo is itself a commit; nothing is rewritten

# reset: moves your branch pointer BACK. Rewrites history. For local only.
git reset --soft  <commit>  # undo commits, KEEP changes staged
git reset --mixed <commit>  # undo commits, keep changes unstaged (default)
git reset --hard  <commit>  # undo commits AND discard changes (dangerous)

The rule: **revert for commits others have seen (it's a forward-moving, safe undo), `resetfor local cleanup**. Andreset --hard` is the one genuinely destructive command here — it throws away changes. Even then, committed work it "removed" is usually recoverable via the next tool.

The Safety Net: git reflog

Here’s the command that turns Git from scary to safe. git reflog records every place HEAD has been — every commit, reset, rebase, checkout — even ones no longer on any branch:

git reflog                  # a list of everywhere HEAD has been, with hashes
git reset --hard HEAD@{2}   # jump back to where you were 2 moves ago

Did a reset --hard and panic? Did a rebase go wrong and "lose" commits? reflog still has the old position. Find the hash, reset or checkout back to it, and your "lost" work reappears. As long as a change was committed at some point, reflog can almost always bring it back (for ~90 days by default).

Putting It Together

A quick map of “undo” by situation:

1. Unsaved file edits → git restore <file>.
2. Wrongly staged → git restore --staged <file>.
3. Bad last commit → git commit --amend (local only).
4. Undo a commit, shared → git revert. Local cleanup → git reset.
5. “I lost commits!” → git reflog, find the hash, reset back.

The Takeaway

The anxiety that surrounds Git comes almost entirely from believing your work is one wrong command away from oblivion. It isn’t. Git is a history machine designed to let you move back and forth safely — discard unsaved edits, unstage files, amend commits, revert or reset history, and recover “lost” commits from the reflog. Learn the right undo for each of the three areas, keep git reflog in your back pocket as the ultimate safety net, and Git stops being something you tiptoe around. Commit often, experiment freely, and trust that you can almost always get back.

This is Part 2 of the Git & Version Control Mastery series. Next up: git bisect — how to find the exact commit that introduced a bug, automatically.

What’s the scariest Git situation you’ve recovered from? 👇