Undoing Mistakes Safely: restore, reset, revert and amend

An Eraser, a Correction Note and a Torn Page

Think about the different ways to fix a mistake in a school notebook:

• With a pencil, you rub it out with an eraser before anyone sees it. Easy and private.
• In the class attendance register, a teacher never erases. She writes a correction note: “Entry of 5 March corrected, student was present.” The old entry and the fix are both visible.
• Or you could tear out the page. That removes the mistake, but also everything else on that page, and you cannot easily get it back.

Git has all three kinds of undo, and choosing the right one matters. Some are completely safe, and some can delete your work. In this lesson Asha Verma makes some very normal mistakes on the Utsav fest website, and you will learn which tool fixes each one: git restore, git commit --amend, git revert and git reset.

The Eraser: Discard Changes with git restore

In the last lesson, Asha found that she had changed the Dance Battle time to 5 PM by mistake. The change is only in her working folder; it was never committed. She wants the file to look exactly like the last commit again:

# Throw away the unsaved changes in one file
# and go back to the version in the last commit
git restore index.html

# Throw away changes in every file in this folder (careful!)
git restore .

The file goes back to its committed version. There is no output when it works. Run git status to confirm that the file is no longer listed as modified.

Warning: git restore on a file throws away your uncommitted changes, and Git cannot bring them back, because they were never saved in a commit. Check with git diff first, so you know exactly what you are throwing away.

Older guides use git checkout -- index.html for the same job. git restore is the modern command, and its name says clearly what it does.

Taking Something Out of the Box: git restore --staged

Asha runs git add . and then notices it also staged notes.txt, her private to-do list. She does not want to delete the file; she just wants it out of the box:

# Take notes.txt out of the box, but keep my changes in the file
git restore --staged notes.txt

# Check the result
git status

You will see something like:

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   index.html

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	notes.txt

index.html is still staged, and notes.txt is back on the desk. The file itself is not changed at all. This command is completely safe. (Older guides write git reset HEAD notes.txt.)

Fixing the Last Commit: git commit --amend

Asha commits the new sponsors section and then sees two problems: the message says “Add sponser logos” with a spelling mistake, and she forgot to stage sponsors.css. She does not need a second commit called “oops”. She can amend (correct) the last commit:

# Fix only the message of the last commit
git commit --amend -m "Add sponsor logos section"

# Forgot a file? Stage it, then add it to the last commit
git add sponsors.css
git commit --amend --no-edit

--no-edit means “keep the message as it is”. You will see something like:

[main f6a7b8c] Add sponsor logos section
 Date: Tue Sep 9 18:20:45 2026 +0530
 2 files changed, 24 insertions(+)
 create mode 100644 sponsors.css

Notice the hash changed. Amending does not edit the old commit; it replaces it with a new one. That is fine on your own computer. But once you have shared a commit with others (you will learn to push to GitHub in a later lesson), replacing it causes confusion for your teammates.

Rule: amend only commits that you have not pushed yet. For commits that are already shared, use git revert.

The Correction Note: git revert

Yesterday, Asha committed “Add Coding Contest to Day 2”. Now the fest committee has moved the contest to another day, and her friends already have this commit. She must not tear out the page. Instead she writes a correction note:

# Find the commit to undo
git log --oneline -n 3

# Make a new commit that does the opposite of c3d4e5f
git revert c3d4e5f --no-edit

You will see something like:

[main d4e5f6a] Revert "Add Coding Contest to Day 2"
 1 file changed, 1 deletion(-)

git revert creates a new commit that does the exact opposite of the old one. Lines the old commit added are removed, and lines it removed are put back. Without --no-edit, Git opens your editor so you can change the message; save and close it to finish.

Before:   A---B---C            (C added the Coding Contest)

After:    A---B---C---C'       (C' removes it again)

Nothing is deleted. The mistake and its fix are both in the history.

Because nothing is deleted from the history, git revert is the safe choice for work that others already have. It is like the teacher’s correction in the register: honest and easy to follow.

Tearing Out Pages: git reset

git reset moves your branch back to an older commit, as if the later commits never happened. HEAD~1 means “one commit before the current one”, and HEAD~2 means two commits before. The question is what happens to the changes in the removed commits. That depends on the mode:

Before reset:   A---B---C---D   <- main (HEAD)

git reset --soft HEAD~2
After:          A---B           <- main (HEAD)
                The changes from C and D are STAGED (in the box).

git reset --mixed HEAD~2   (same as plain git reset HEAD~2)
After:          A---B           <- main (HEAD)
                The changes from C and D are in your files, NOT staged.

git reset --hard HEAD~2
After:          A---B           <- main (HEAD)
                The changes from C and D are GONE from your files.

# Undo the last commit, keep its changes staged
git reset --soft HEAD~1

# Undo the last commit, keep its changes in the files (unstaged)
git reset HEAD~1

# DANGER: undo the last commit AND delete its changes
git reset --hard HEAD~1

When is reset useful? Asha made two quick experiment commits, “Try countdown timer” and “Try new colour theme”, and has not shared them. With git reset --soft HEAD~2 she can turn them into one clean commit: the changes stay staged, and she commits again with a better message. With git reset --hard HEAD~2 she throws both experiments away completely.

Big warning about --hard: git reset --hard deletes changes from your files, including any uncommitted edits in tracked files. Uncommitted work lost this way cannot be recovered. Before you use it, run git status and git diff, and make sure you really want to lose everything shown. Like --amend, use reset only on commits you have not pushed.

The Safety Net: git reflog

Here is some good news. Even after a git reset --hard, the commits you removed are not gone straight away. Git keeps a private diary of every place HEAD has pointed to, called the reflog (reference log):

# Show everywhere HEAD has been recently
git reflog

You will see something like:

b2c3d4e (HEAD -> main) HEAD@{0}: reset: moving to HEAD~2
d4e5f6a HEAD@{1}: commit: Try new colour theme
c3d4e5f HEAD@{2}: commit: Try countdown timer
b2c3d4e (HEAD -> main) HEAD@{3}: commit: Add event schedule section

The newest entry is at the top. HEAD@{0} is where you are now, HEAD@{1} is where you were one step before, and so on. Asha regrets throwing away the colour theme, so she goes back to the commit just before the reset:

# Go back to the commit before the reset
git reset --hard d4e5f6a

Both experiment commits are back. You could also write git reset --hard HEAD@{1}. The reflog exists only on your computer, and Git cleans out old entries after some weeks (by default, entries for removed commits are kept for about 30 days), so do not rely on it forever. And remember: it saves commits, not changes you never committed.

Real-Life Example: Which Undo Do I Need?

Asha pins this table above her desk. Find your situation in the left column:

Try these changes:

1. In a practice repository, make a commit, then use git reset HEAD~1 and look at git status. Your changes are in the files but not staged.
2. Run git reflog and find the commit you just removed.
3. Revert your latest commit and read the new message Git writes for you in git log.

Common Mistakes

• Using git reset --hard as a general undo button. It deletes uncommitted work. Most of the time git restore, --soft or git revert is what you want.
• Amending or resetting commits that are already shared. Your teammates then have commits that no longer exist in your history. Use git revert for shared work.
• Confusing restore and restore --staged. Without --staged, your edits are thrown away. With it, the file only leaves the box.
• Expecting git revert to remove the commit from the log. It adds a new commit. The original stays in the history on purpose.
• Panicking after a bad reset. Stop, run git reflog, and look for the commit you want back.

Practice Task: Make Mistakes on Purpose

Create a new practice repository called undo-practice with one commit of an index.html file. Then, in your own terminal:

1. Edit index.html, save, and throw the change away with git restore.
2. Create notes.txt, stage it, then unstage it.
3. Commit a change with the message “Add shedule section”, then fix the spelling with --amend.
4. Commit a new line, then undo it with git revert. Look at git log --oneline.
5. Undo the last commit with git reset --soft HEAD~1 and check git status.
6. Use git reflog to find that commit again and go back to it.

Checklist:

• git status is clean after step 1
• notes.txt is untracked after step 2
• The log shows the corrected spelling, not “shedule”
• After step 6, the log looks the same as it did before step 5

# Setup: a practice repository
cd ~/Desktop
mkdir undo-practice
cd undo-practice
git init -b main
# create index.html with a heading, then:
git add index.html
git commit -m "Add home page"

# 1. Edit index.html, save, then throw the change away
git restore index.html
git status            # working tree clean

# 2. Create notes.txt, stage it, then unstage it
git add notes.txt
git restore --staged notes.txt
git status            # notes.txt is untracked again

# 3. Commit a change with a spelling mistake, then fix the message
git add index.html
git commit -m "Add shedule section"
git commit --amend -m "Add schedule section"

# 4. Add a line, commit it, then revert that commit
git add index.html
git commit -m "Add sponsors line"
git revert HEAD --no-edit
git log --oneline     # both commits are in the history

# 5. Undo the last commit with reset, keeping the changes
git reset --soft HEAD~1
git status            # the changes are staged

# 6. Use reflog to find the commit you just reset away and go back
git reflog
git reset --hard HEAD@{1}

Key Takeaways

• git restore file discards uncommitted edits; git restore --staged file only unstages.
• git commit --amend fixes the last commit’s message or contents, but only before you push.
• git revert makes a new commit that undoes an old one. It is the safe choice for shared history.
• git reset moves the branch back: --soft keeps changes staged, --mixed keeps them unstaged, and --hard deletes them.
• git reflog is your safety net for finding commits you removed by mistake.
• When unsure, run git status and git diff first, and choose the safest undo that does the job.