Undoing Things Safely: Restore, Reset, Revert, Reflog and Friends

Beginners fear Git because one wrong command seems to destroy work. In practice, once something is committed, it is very hard to lose it for good. What you can lose easily is work that was never committed. This lesson shows the undo tools one by one, each with a real run, and ends with a table you can keep next to your keyboard.

It builds on lesson 0 (commits and pointers) and lesson 3 (remotes). The idea that matters most: local history that nobody has seen can be rewritten. History that is already shared should only get new commits on top.

Words used in this lesson

• To restore is to put file content back from the staging area or from a commit.
• To amend is to replace the last commit with a new, corrected one.
• To reset is to move the current branch to another commit (and optionally change the staging area and files).
• To revert is to make a new commit that undoes an older commit.
• The reflog is Git's private diary of where HEAD and each branch pointed. Entries expire after some time (the defaults in Documentation/config/gc.adoc are 90 days for reachable entries and 30 days for unreachable ones), so it is a short-term safety net.
• A stash is a shelf where Git keeps unfinished changes so you can switch tasks.
• To cherry-pick is to copy one commit onto the current branch as a new commit.
• Bisect is a binary search through history to find the commit that introduced a bug.

Start here: what do I want to undo?

Restore: undo edits to files

git restore puts file content back. It replaced the old, confusing uses of git checkout -- file and git reset HEAD file.

echo "oops" >> app.txtgit status --shortgit restore app.txtcat app.txtgit status --short

 M app.txtv1

The edit is gone, and status is clean. This cannot be undone. Git never saw those edits as a commit, so there is nothing to bring back. Run git diff first when you are not sure.

To unstage a file (the edits stay on disk):

echo "staged mistake" > secret.txtgit add secret.txtgit status --shortgit restore --staged secret.txtgit status --short

A  secret.txt?? secret.txt

To get an old version of a file from another commit, use --source. I restored app.txt from the commit before the last one; it contained v1 again and status was clean. (In that run the old and the current versions were the same, so use a file that really changed when you try it.) Use git restore --source=HEAD~2 --staged --worktree file to restore both the staging area and the file.

Amend: fix the last commit

I made a commit with a typo in the message:

git commit -m "Add b.txt wrng"git commit --amend -m "Add b.txt"

I also forgot a file. Stage it and amend with --no-edit (keep the message):

echo "bb" > bb.txt && git add bb.txtgit commit --amend --no-editgit log --oneline -3git show --stat --format=%s HEAD

49924a8 Add b.txt1a01d5c Add a.txt3d03bdf Add app v1Add b.txt b.txt  | 1 + bb.txt | 1 + 2 files changed, 2 insertions(+)

The hash changed each time: the message Add b.txt wrng was commit 9f01fe8, the first amend made 16632af and the last 49924a8. As lesson 0 explained, an amended commit is a new commit. The old ones are still in the object store (the reflog lists both amends). That is fine on a local commit. It is a problem if you already pushed, because your teammates have the old one.

Reset: move the branch

git reset <commit> moves the current branch to <commit>. The three modes differ in what happens to the staging area and the working tree:

Three commits f1, f2, f3 (newest c2df1d0 Add f3, then 6bd2f39 Add f2) sit on top of the earlier ones.

Soft: un-commit f3, keep it staged. Good for "I want to redo this commit".

git reset --soft HEAD~1git status --shortgit log --oneline | head -2

A  f3.txt6bd2f39 Add f2892a13b Add f1

Mixed (the default): I recommitted, then un-committed again without any flag. The file stays on disk but is no longer staged. Good for "I want to split this into smaller commits".

git commit -qm "Add f3 again"git reset HEAD~1git status --short

?? f3.txt

Hard: I committed again, then ran:

git reset --hard HEAD~1git status --shortls

HEAD is now at 6bd2f39 Add f2a.txtapp.txtb.txtbb.txtf1.txtf2.txt

f3.txt is gone from the disk, too. If f3 had never been committed, those edits would be lost forever. Because it was committed, we can get it back with the reflog.

Reflog: recover a lost commit

The reflog records every move of HEAD. I made a clean example: three commits, then a hard reset by two.

git log --onelinegit reset --hard HEAD~2git log --onelinels

9208aaa Add n34ff95ea Add n2e05f10d Add n1HEAD is now at e05f10d Add n1e05f10d Add n1n1.txt

n2 and n3 seem gone. Look at the diary:

git reflog

e05f10d HEAD@{0}: reset: moving to HEAD~29208aaa HEAD@{1}: commit: Add n34ff95ea HEAD@{2}: commit: Add n2e05f10d HEAD@{3}: commit (initial): Add n1

The commits are right there. HEAD@{1} is "where HEAD was one move ago". Go back:

git reset --hard 'HEAD@{1}'git log --onelinels

HEAD is now at 9208aaa Add n39208aaa Add n34ff95ea Add n2e05f10d Add n1n1.txtn2.txtn3.txt

Everything is back. The same trick recovers a deleted branch. I made a branch risky with one commit, switched away and deleted it with -D:

git branch -D riskygit reflog | head -3git branch rescued 'HEAD@{1}'git log --oneline rescued | head -2

Deleted branch risky (was b78fe8f).9208aaa HEAD@{0}: checkout: moving from risky to mainb78fe8f HEAD@{1}: commit: Risky work9208aaa HEAD@{2}: checkout: moving from main to riskyb78fe8f Risky work9208aaa Add n3

Notice that Git even printed the old hash when it deleted the branch: was b78fe8f. Write that hash down and you can always make the branch again with git branch name b78fe8f.

Limits of the reflog: it is local (it is not pushed, and a new clone has no reflog), it only covers commits that HEAD or a branch pointed to, and old entries are removed after a time. It does not save uncommitted work. git fsck --lost-found can list dangling commits and blobs too; in my test it printed a few dangling commit lines.

Revert: undo a commit on shared history

Reset rewrites history. If the bad commit is already on the shared main, don't rewrite. Add a new commit that does the opposite:

git log --onelinegit revert --no-edit HEAD~1git log --oneline | head -4ls

Before this, the history ended with Add ok file (top) on Add bad feature. The revert of the older of the two:

[main 3ec3bd3] Revert "Add bad feature" 1 file changed, 1 deletion(-) delete mode 100644 bad.txt3ec3bd3 Revert "Add bad feature"28b27de Add ok file6165daf Add bad feature9208aaa Add n3

bad.txt was removed, ok.txt is still there, and the bad commit is still in the log. Nothing was rewritten, so it is safe for everyone. The new commit message says This reverts commit 6165daf....

Reverting a merge needs one extra option, because a merge has two parents and Git does not know which side to keep. I tried:

error: commit 4e6804d... is a merge but no -m option was given.fatal: revert failed

git revert -m 1 <merge> means "keep parent 1 (the mainline) and undo what the other side brought". It worked and deleted s.txt, the file the side branch had added.

Stash: park unfinished work

You are half-way through something and must switch to an urgent fix. Don't commit half-done code. Stash it:

git status --shortgit stashgit status --shortgit stash list

 M notes.txt?? scratch.txtSaved working directory and index state WIP on main: 23a5697 Add notes?? scratch.txtstash@{0}: WIP on main: 23a5697 Add notes

By default stash saves changes to tracked files. The untracked scratch.txt stayed behind. Add -u to include untracked files, and -m for a name:

git stash popgit stash push -u -m "wip with scratch"git stash list

stash@{0}: On main: wip with scratch

(git stash pop first brought back the edit and dropped the stash, Dropped refs/stash@{0}.) Now the working tree is clean. Do the urgent work, switch back, then:

git stash pop re-applies the newest stash and deletes it. git stash apply re-applies but keeps it. git stash list shows all, and git stash drop deletes the newest.

If a pop conflicts with newer changes, Git keeps the stash so you do not lose it.

Cherry-pick: copy one commit

A feature branch has three commits, and the middle one is a small fix that main needs today:

* cc1bd06 Feature: part 2* e866b40 Fix typo in config* 3478903 Feature: part 1* 7f7cecb Base

git switch maingit cherry-pick feature~1git log --oneline --graph --all

[main 4753df3] Fix typo in config 1 file changed, 1 insertion(+) create mode 100644 fix.txt* cc1bd06 Feature: part 2* e866b40 Fix typo in config* 3478903 Feature: part 1| * 4753df3 Fix typo in config|/* 7f7cecb Base

The fix is on main as a new commit (4753df3) with the same change but a different hash, because it has a different parent. Add -x to record the original hash in the message:

Feature: part 1(cherry picked from commit 347890386a9d34cadca50f7fdf5cb2081d34f4ac)

If the change does not fit, you get a conflict like in lesson 2. Resolve it and run git cherry-pick --continue, or give up with git cherry-pick --abort. In my run, the conflicted pick showed UU app.txt in git status --short, and --abort made everything clean again.

Use cherry-pick sparingly, for example for a hotfix on a release branch.

Bisect: find the commit that broke it

You know the code worked last week and is broken now. Between them are 13 commits. Instead of reading all of them, let Git do a binary search. It checks out the middle commit, you say good or bad, and it halves the range. With 13 commits this takes about 4 steps (log2(13) is about 3.7).

I made a script test.sh that exits with 0 when calc.sh 2 3 prints 5, and 1 otherwise. A commit called "Refactor calc arithmetic" changed + to - by mistake, in the middle of unrelated commits.

sh test.sh; echo "test exit: $?"git bisect startgit bisect bad                  # current commit is brokengit bisect good HEAD~13         # this old one workedgit bisect run sh ./test.sh     # let Git run the test at each step

test exit: 1status: waiting for both good and bad commitsstatus: waiting for good commit(s), bad commit knownBisecting: 6 revisions left to test after this (roughly 3 steps)[439f3af907d6e01c4589a93b6419818bd1f047b9] Change 7running 'sh' './test.sh'Bisecting: 3 revisions left to test after this (roughly 2 steps)[3ec7d0aa2ffe3079c20c74da97da471aafa3badc] Refactor calc arithmeticrunning 'sh' './test.sh'Bisecting: 0 revisions left to test after this (roughly 1 step)[f0b82dd95e395a2ac2cc62ba4abe783adbec4f1e] Change 9running 'sh' './test.sh'3ec7d0aa2ffe3079c20c74da97da471aafa3badc is the first bad commitcommit 3ec7d0aa2ffe3079c20c74da97da471aafa3badcAuthor: Ada Lovelace <ada@example.com>Date:   Thu Jan 1 10:00:00 2026 +0000    Refactor calc arithmetic calc.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)bisect found first bad commit

Git tested only three commits and named the guilty one. Without run, you do the testing by hand and type git bisect good or git bisect bad at each step. The script contract (from the Git manual): exit 0 means good, 1 to 127 (except 125) means bad, and 125 means "cannot test this commit, skip it". Always finish with:

git bisect reset

This returns you to the branch you started on. Small, working commits (lesson 1) make bisect precise.

A safety checklist

Run git status before big commands. Commit or stash first, because committed work is recoverable. Make a backup branch (git branch backup-before-rebase) before anything risky. Never rewrite history that others already have; use revert. After a mistake, stop, run git reflog, and think before the next command.

Try it

Use a practice repository with at least four commits.

1. Change a tracked file, then discard the change with one command. Then stage a change and unstage it without losing it.
2. Make a commit with a wrong message. Fix it. Does the hash change?
3. Make three commits. Use git reset --soft HEAD~3 and make them one commit. What does the soft reset leave in the staging area?
4. Run git reset --hard HEAD~1. Use the reflog to bring the commit back. What did you type?
5. Create a branch with one commit, delete it with -D, and bring the branch back.
6. Introduce a bug in the middle of ten commits, and find it with git bisect run.
7. For each case, say whether you would reset or revert: (a) your own commit that you have not pushed; (b) a commit that is on main and was released yesterday.

Answers

1. git restore file discards. For the second part git add file, then git restore --staged file; the edits stay in the file.
2. git commit --amend -m "New message". Yes, the hash changes, because the message is part of the commit.
3. All the changes of the three commits, staged and ready. A single git commit -m "..." creates the combined commit.
4. git reflog shows HEAD@{1}: commit: ..., then git reset --hard 'HEAD@{1}' (or the hash).
5. git branch -D name prints was <hash>. Recreate it with git branch name <hash>, or find the hash in git reflog.
6. Write a test script that exits 1 when the bug is present. Then git bisect start, git bisect bad, git bisect good <old>, git bisect run ./test.sh, and finally git bisect reset.
7. (a) Reset (or amend) is fine because nobody else has the commit. (b) Revert, because it is shared and released; rewriting it would break everyone's copy.

Interview questions

Key takeaways

• Committed work is hard to lose. Uncommitted work is easy to lose. Commit or stash first.
• restore is for files, reset moves the branch, revert adds an undo commit. Use revert on shared history.
• reset --soft keeps changes staged, --mixed keeps them unstaged, --hard throws them away.
• git reflog is your undo log for HEAD and branches. It is local and it expires.
• stash parks work (-u for untracked files), cherry-pick copies one commit, bisect run finds the guilty commit.
• After a mistake: stop, git status, git reflog, think, then act.

What's next

Next: Rebase, clean history and team workflows, Lesson 5. You will learn when to rebase instead of merge, how to squash and reword commits, why --force-with-lease is safer than --force, and how teams protect main with branch rules, CODEOWNERS and CI. Practise now: pick a repository, create a backup branch, and try each reset mode on it, then fix it with the reflog.