Git Course 0%

Undo, beginner edition

Beginner Git CLI VS Code UI IntelliJ UI GitLab UI GitHub UI ≈ 12 min

Before this lesson

What you will learn

  • Which undo applies to which stage: working tree, staging area, last commit, older commit
  • The exact commands, and which of them destroy uncommitted work
  • What to leave for the recovery section: reset --hard, force push, rebase

After this lesson you can

  • I can undo a wrong edit, a wrong staging, a wrong message and a wrong commit without help
  • I know the two commands that lose work and pause before each

Why this matters

Mistakes are the normal texture of Git work: an edit in the wrong file, a file staged by accident, a commit with a typo, a change that turned out wrong. Each stage has one clean undo. Learn those four, and the fear goes away; leave the powerful ones for Section 12, when you have branches and remotes to recover from.

The map

The mistake is in… Undo with Loses work?
the working tree (an edit you do not want) git restore <file> Yes: the uncommitted edit is gone
the staging area (staged the wrong file) git restore --staged <file> No: the edit stays in the working tree
the last commit (message or a forgotten file), not pushed git commit --amend No
a commit that was pushed or is older than the last git revert <hash> No: a new commit undoes it

Everything else (reset --hard, push --force, rebase, checkout of old commits) belongs to Section 12.

1. Discard an edit

You changed a file and want the committed version back:

Terminal
$ git status -s
 M README.md
Terminal
$ git restore README.md
$ git status -s

Silence: the file matches the last commit again (or the staged version, if one exists). This is the one everyday command that throws work away without a way back, so look at git diff <file> first and be sure.

2. Unstage

You staged a file that should not be in the next commit:

Terminal
$ git status -s
M  docs/faq.md
Terminal
$ git restore --staged docs/faq.md
$ git status -s
 M docs/faq.md

The M moved from the first column to the second: no longer staged, still edited. Nothing lost. To also drop the edit, follow with plain git restore docs/faq.md.

3. Fix the last commit (before pushing)

Forgot a file:

Terminal
$ git add docs/faq.md
$ git commit --amend --no-edit
[main 8330ba9] feat: add Coast Walk trail (#29)
 Date: Tue Sep 8 10:00:00 2026 +0200
 2 files changed, 5 insertions(+)

Wrong message:

Terminal
$ git commit --amend -m "feat: add Coast Walk trail and FAQ entry (#29)"
[main 778c9e7] feat: add Coast Walk trail and FAQ entry (#29)
 Date: Tue Sep 8 10:00:00 2026 +0200
 2 files changed, 5 insertions(+)

Each amend produces a new hash; the previous commit is replaced. This rewrites history, so: only if you have not pushed (lesson 2.7). After a push, use a new commit.

4. Undo a commit with a new commit

A change is wrong, and it is already pushed, or it is not the last one. git revert creates a new commit that applies the opposite change; history keeps both:

Terminal
$ git revert --no-edit HEAD
[main dc9a369] Revert "feat: add Coast Walk trail and FAQ entry (#29)"
 Date: Tue Sep 8 10:00:00 2026 +0200
 2 files changed, 5 deletions(-)
Terminal
$ git log --oneline -3
dc9a369 Revert "feat: add Coast Walk trail and FAQ entry (#29)"
778c9e7 feat: add Coast Walk trail and FAQ entry (#29)
c541c80 docs: add maintainer note

The files are as they were before 778c9e7, and the record shows what happened and why. git revert <hash> works on any commit, not just the last; without --no-edit it opens the editor so you can add a reason to the message. Because it only adds a commit, it is always safe to push.

A bonus: one file from an older commit

Not an undo of a commit, but a frequent need — bring back a file's content from an earlier point, into the working tree, without touching anything else:

Terminal
$ git restore --source=HEAD~3 README.md
$ git status -s
 M README.md

The file is now as it was three commits ago, as an uncommitted change you can inspect, commit, or discard.

In the tools

Everything above. Before any git restore without --staged, run git diff <file> and read what you are about to lose.

Common mistakes

  • git restore when git restore --staged was meant. The edit is gone. Read the hint lines in git status; they always say which form.
  • Amending a pushed commit. Diverged branch. Revert or a new commit instead.
  • Reverting a merge commit without -m. Git refuses and explains; that case is in lesson 12.6.
  • Reaching for git reset --hard from a web search. It discards everything uncommitted and moves the branch. Not yet.

Try it yourself

Goal: perform all four undos in the playground.

  1. Edit README.md, check git diff, then discard it with git restore README.md.
  2. Edit docs/faq.md, stage it, then unstage it with git restore --staged docs/faq.md; confirm the edit is still there with git diff, then discard it.
  3. Make a commit with a wrong message (git commit --allow-empty -m "docs: typoo"), then fix it with git commit --amend -m "docs: typo".
  4. Make a real commit (add a line to the FAQ, stage, commit), then git revert --no-edit HEAD and read git log --oneline -3.

Expected result: the tree is clean after 1 and 2; the log shows the corrected message after 3; after 4 the log shows the commit and its revert, and the FAQ no longer has the line.

Show solution

Undo 1 and 2 are working-tree and staging-area operations that leave no trace in history. Undo 3 replaced the commit (new hash). Undo 4 added a commit: git log shows both, and git show HEAD shows the four lines being removed again. That is the complete beginner's toolkit.

Check yourself

1. Which undo command loses uncommitted work?
2. A commit you pushed an hour ago turned out to be wrong. The right tool is…
3. git restore --source=HEAD~3 README.md does what?

Key terms

Restore Staged Commit HEAD

Related