Reset, Revert, and the Reflog

Three areas, one more time

Module 1 introduced git’s three areas, and reset only makes sense with them in mind. Pro Git calls them three trees ¹:

• HEAD: the last commit on your current branch, and the parent of the next one.
• The index (the staging area): your proposed next commit.
• The working directory: the actual files you edit.

git add copies from your files to the index; git commit turns the index into a new commit and moves the branch to it. git reset runs that backward.

What reset does

git reset <commit> moves the branch you’re on so it points at <commit> ¹. Commits after that point are no longer on the branch. Here’s a garden repository with four commits:

me@linuxbox:~/garden$ git log --oneline
92e275f Add squash
dbeefcd Add garlic
d832160 Add beans
e31a769 Plan the beds

HEAD~1 means “one commit before HEAD” (module 2), so git reset HEAD~1 moves main back from 92e275f to dbeefcd. The Add squash commit isn’t deleted. Nothing points at it any more, but it’s still in the repository, and you’ll see below how to get it back.

The three modes

After moving the branch, reset can go on to reset the index, and then your files as well. The mode says how far it goes ^{1 2}.

--soft moves the branch and stops. The undone commit’s changes are still in the index, staged:

me@linuxbox:~/garden$ git reset --soft HEAD~1
me@linuxbox:~/garden$ git status -s
M  beds.txt
me@linuxbox:~/garden$ git log --oneline
dbeefcd Add garlic
d832160 Add beans
e31a769 Plan the beds

The M in the first column means staged (module 1). It’s as if you’d run git add but not git commit, so you can change something and commit again.

--mixed is the default when you give no mode. It moves the branch and makes the index match it, so the changes are left in your files, unstaged ¹. Going back one more commit:

me@linuxbox:~/garden$ git reset HEAD~1
Unstaged changes after reset:
M   beds.txt
me@linuxbox:~/garden$ git status -s
 M beds.txt
me@linuxbox:~/garden$ git diff
diff --git a/beds.txt b/beds.txt
index ff39cfb..99dea17 100644
--- a/beds.txt
+++ b/beds.txt
@@ -1,2 +1,4 @@
 # Garden beds
 beans
+garlic
+squash

Both undone commits’ changes are in the file, as if you’d never run git add or git commit on them.

--hard moves the branch, resets the index, and overwrites your files to match ²:

me@linuxbox:~/garden$ git reset --hard HEAD
HEAD is now at d832160 Add beans
me@linuxbox:~/garden$ git status -s
me@linuxbox:~/garden$ git log --oneline
d832160 Add beans
e31a769 Plan the beds

git reset --hard HEAD doesn’t move the branch at all; it just throws away every uncommitted change. The garlic and squash lines are gone from the file.

Pro Git singles out --hard as the one form of reset that’s dangerous, and one of very few commands where git destroys data ¹. Committed work can be recovered, as you’re about to see. Uncommitted edits that --hard overwrites cannot. Before running it, git status and git diff to check what you’d lose, and commit or stash anything you might want (next lesson covers stash).

Given a file name instead of a commit, git reset beds.txt only copies that file from HEAD into the index: it unstages it ¹. That’s what older versions of git status suggested for unstaging; git restore --staged (module 2) does the same job and is clearer.

Reset or revert?

Both undo commits, in opposite ways:

• git reset rewrites history: the branch moves back, and the commits drop off it.
• git revert (module 2) adds history: a new commit that does the opposite of an old one ³.

The rule is the same as for rebasing. If a commit is only on your computer, reset freely. If you’ve pushed it and anyone else might have it, revert. Resetting a shared branch means force-pushing, and everyone else’s copy then disagrees with yours.

The reflog: getting it back

Every time HEAD moves, by a commit, a reset, a switch, a merge, or a rebase, git writes a line in the reflog, the reference log ⁴. After the resets above, it looks like this:

me@linuxbox:~/garden$ git reflog
d832160 HEAD@{0}: reset: moving to HEAD
d832160 HEAD@{1}: reset: moving to HEAD~1
dbeefcd HEAD@{2}: reset: moving to HEAD~1
92e275f HEAD@{3}: commit: Add squash
dbeefcd HEAD@{4}: commit: Add garlic
d832160 HEAD@{5}: commit: Add beans
e31a769 HEAD@{6}: commit (initial): Plan the beds

Newest first. HEAD@{3} means “where HEAD was three moves ago” ⁴, and that’s 92e275f Add squash, from before all the resets. Put main back there:

me@linuxbox:~/garden$ git reset --hard HEAD@{3}
HEAD is now at 92e275f Add squash
me@linuxbox:~/garden$ git log --oneline
92e275f Add squash
dbeefcd Add garlic
d832160 Add beans
e31a769 Plan the beds

All four commits are back. You could equally use the ID, git reset --hard 92e275f, or make a branch there with git branch rescue 92e275f to look before you leap.

For the last reset only, there’s a shortcut. Reset saves the previous tip of the branch as ORIG_HEAD ², so the newest reset can be undone directly:

me@linuxbox:~/garden$ git reset --hard HEAD~2
HEAD is now at d832160 Add beans
me@linuxbox:~/garden$ git reset --hard ORIG_HEAD
HEAD is now at 92e275f Add squash

Two limits to know ⁴:

• The reflog is local. It records moves in your repository; it isn’t pushed, and a fresh clone starts with an empty one.
• Entries expire. By default, git’s housekeeping prunes reflog entries after 90 days, and after 30 days for commits no longer on any branch. So a commit lost to a reset has about a month.

Each branch has its own reflog too: git reflog main shows only the moves of main, and main@{one.week.ago} names where main pointed a week ago ⁴.

Two recipes

Squash your last few commits into one. --soft keeps the changes staged, so recommitting folds them together ²:

me@linuxbox:~/garden$ git reset --soft HEAD~2
me@linuxbox:~/garden$ git commit -m "Add garlic and squash"
[main f8509eb] Add garlic and squash
 1 file changed, 2 insertions(+)
me@linuxbox:~/garden$ git log --oneline
f8509eb Add garlic and squash
d832160 Add beans
e31a769 Plan the beds

This does the same job as squashing in git rebase -i (module 3), with less ceremony when it’s the last few commits.

Committed to main when it should have been a branch. Make a branch where you are, so the commits keep a name, then move main back. The git docs give this recipe for three commits ²:

me@linuxbox:~/garden$ git branch fence-plan
me@linuxbox:~/garden$ git reset --hard HEAD~3
me@linuxbox:~/garden$ git switch fence-plan

main is back where it was, and the three commits live on fence-plan. Do this before you push main.

Your turn

So

git reset <commit> moves your branch back. --soft leaves the undone changes staged, --mixed (the default) leaves them in your files, and --hard throws them away, which is the one way reset loses uncommitted work. Reset only commits nobody else has; for shared ones, git revert. Committed work isn’t easily lost: git reflog lists everywhere HEAD has been, git reset --hard HEAD@{n} goes back there, and ORIG_HEAD undoes the last reset.