Undoing Changes: restore, reset & revert

Everyone makes mistakes in Git — the trick is knowing the right tool to fix each one. By the end of this lesson you'll confidently pick between git restore, the three modes of git reset, and git revert, and you'll know which ones are safe and which are destructive.

Learn Undoing Changes: restore, reset & revert in our free Git course — a beginner-friendly interactive lesson with worked examples, a practice exercise and…

Part of the free Git course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

What You'll Learn

1️⃣ git restore — Undo Working-Tree Changes

git restore is the modern, focused way to undo file changes. With no flag it discards unstaged edits , snapping a file back to its last committed state — this is destructive for those edits, so be sure. Add --staged and it instead unstages a file while leaving your edits untouched. Same command, two jobs, split by one flag.

2️⃣ git reset — Move the Branch Pointer

git reset moves your branch back to an earlier commit. The mode decides what happens to the changes from the commits you drop. --soft keeps them staged (ideal for re-doing the last commit). --mixed (the default) keeps them unstaged in your working tree. --hard discards them entirely — that one is destructive, so reach for it carefully.

3️⃣ git revert — The Safe Undo

When a commit is already pushed and shared , rewriting history with reset would break everyone who pulled it. git revert avoids that: it creates a new commit that applies the inverse of the target. History only grows, so collaborators stay in sync. This is the undo you'll use most on shared branches.

Your turn. Match each undo to its situation by filling in the three blanks.

Common Errors (and the fix)

• Used --hard and lost uncommitted work: uncommitted changes are unrecoverable. If the work was committed first, git reflog can often find it again.
• reset on a pushed branch broke teammates: reset rewrites history. On shared branches use git revert instead — it never rewrites.
• "error: pathspec did not match" with git restore: you mistyped the file path, or the file is untracked (restore only knows tracked files). Check git status .
• Confused soft and hard: remember --soft keeps work staged; --hard deletes it. When unsure, never use --hard .

Pro Tips

• 💡 Commit before experimenting: a commit is a safety net — reflog can rescue committed work, never uncommitted.
• 💡 Default to revert on shared branches: if anyone else has the commit, revert, don't reset.
• 💡 Read status after every undo: confirm the result before doing anything else.
• 💡 Save destructive resets for throwaway state: --hard is great to abandon a local mess, terrible by accident.

📋 Quick Reference

Command

Purpose

git restore file

Discard unstaged edits to a file

git restore --staged file

Unstage a file, keep the edits

git reset --soft HEAD~1

Un-commit, keep changes staged

git reset HEAD~1

Un-commit, keep changes unstaged (default)

git reset --hard HEAD~1

Un-commit and discard changes (destructive)

git revert <commit>

Undo a commit with a new commit (safe)

Frequently Asked Questions

Mini-Challenge: Choose Your Undo

No commands given this time — just three real situations. Decide which undo fits each, then prove it in a throwaway repo.

🎉 Lesson Complete!

• ✅ git restore discards unstaged edits; --staged unstages
• ✅ reset --soft keeps work staged, --mixed unstages, --hard deletes
• ✅ --hard is destructive for uncommitted work — no undo
• ✅ git revert safely undoes shared commits by adding a new one
• ✅ Reset rewrites history; revert preserves it — choose by who else has the commit
• ✅ Next lesson: shelve work in progress with git stash

Practice quiz

Continue this course

• Previous: The Staging Area & git diff
• Next: Stashing Work in Progress