git reset vs git revert: Which One Should You Use to Undo?

Both commands "undo" commits, but in opposite ways:

• git revert adds a new commit that reverses an old one. History is kept.
• git reset moves your branch back to an earlier commit, as if later commits never happened. History is rewritten.

The rule that keeps you out of trouble:

Already pushed and shared? Use revert. Only on your machine? Reset is fine.

git revert: undo by adding

git revert a1b2c3d

Git creates a new commit that does the exact opposite of a1b2c3d. Your history now shows both: the original change and its reversal.

A — B — C — C'   (C' undoes C)

Why it's safe: nobody else's copy of the branch is invalidated. You push the new commit like any other. It's the right way to undo something on main that's already deployed.

Revert the most recent commit:

git revert HEAD

If later commits touched the same lines, you may get a conflict to resolve. (Merge conflicts explained)

git reset: undo by moving back

git reset --mixed HEAD~1

Your branch now points one commit earlier. Commit C is no longer on the branch:

A — B        (C is gone from the branch)

The three modes

What happens to the changes from the removed commits depends on the mode:

Mode	Commits	Staged changes	Your files
--soft	Removed	Changes kept staged	Unchanged
--mixed (default)	Removed	Changes kept, unstaged	Unchanged
--hard	Removed	Discarded	Reset — changes lost

Common uses:

git reset --soft HEAD~1    # "undo the commit, keep everything ready to recommit"
git reset HEAD~3           # squash the last 3 commits into one new commit
git reset --hard HEAD      # throw away all uncommitted changes
git reset --hard origin/main  # make my branch exactly match the remote

--soft is how you fix "I committed too early" or "wrong commit message". --hard is the dangerous one — uncommitted work is gone.

Why not reset shared branches?

If you reset a branch others have already pulled and then force-push, their copies still contain the commits you removed. Their next pull gets confusing, and work can be lost. That's why git push refuses after a reset — you'd need --force — and that refusal is a useful warning. (Git push rejected)

On your own feature branch that nobody else uses, resetting and force-pushing (--force-with-lease) is normal.

Oops: recovering from a bad reset

Commits removed by reset aren't deleted immediately. git reflog lists everywhere your branch has pointed recently:

git reflog
# a1b2c3d HEAD@{1}: commit: Add pricing page
git reset --hard a1b2c3d

This works for committed work. Changes that were never committed and then wiped by reset --hard are not recoverable by Git. (How to undo almost anything in Git)

What about git restore?

For undoing changes to files (not commits), use restore:

git restore app.js            # discard uncommitted changes to a file
git restore --staged app.js   # unstage, keep the changes

Quick decision guide

Situation	Command
Bad commit already pushed to main	git revert <commit>
Last commit, not pushed, want to redo it	git reset --soft HEAD~1
Several messy local commits to combine	git reset HEAD~N, then commit (squash commits)
Throw away all local changes	git reset --hard HEAD (careful)
Discard changes to one file	git restore <file>

With an AI coding tool

Commit before letting an AI tool make big changes. If it goes wrong, git reset --hard back to that commit (if nothing's pushed) or git revert (if it is). (Using Git with Claude Code)

---

EasySpawn keeps your repository and its full history on a persistent server, so an undo is always one Git command away — from your laptop, phone or browser. See how it works or join the waitlist.

Related: How to Undo Almost Anything in Git · Git Rebase vs Merge · How to Squash Commits · Git Push Rejected