The git reflog (Reference Log) tool is an internal Git lifesaver that keeps a complete record of every time the local pointer has been updated in your repository.
We’ve seen that using commands like git reset --hard carries a very real risk of losing information.
You get carried away. You think “I’m going to clean up this history” and run a git reset --hard. Then you realize that in that commit you just deleted there was a file you don’t have anywhere else.
You do git log and, indeed, the commit is gone. It’s no longer there. By rewriting history, the deleted commits disappear from the standard history (git log).
But there is still a tool that could save the situation. The Reference Log (Reflog). You can access it with git reflog.
What is the Reflog?
It’s normal to think that when you do a git reset, commits “get deleted”. That’s not entirely true. Git rarely deletes anything immediately. All it does is hide it.
While git log shows you the “public” history of your project, git reflog records every time the HEAD pointer moves on your computer.
- Did you make a commit? It’s logged in the reflog.
- Did you do a reset? It’s logged in the reflog.
- Did you switch branches? It’s logged in the reflog.
The Reflog is a strictly local history. It is not uploaded to GitHub or shared with your teammates. It’s your personal safety net on your machine.
Simulating the Disaster
To understand how it works, let’s cause an accident.
We have a project with 3 commits (A, B, and C).
We are on commit C.
We execute a destructive Hard Reset to go back to A
git reset --hard HEAD~2
If we now do a git log, we only see commit A. Commits B and C have “disappeared”. If we try to find them, they are not in the list. This is where panic sets in.
The Rescue
Take a deep breath and type in your terminal:
git reflog
You’ll see a list somewhat different from the usual one:
a1b2c3d (HEAD -> main) HEAD@{0}: reset: moving to HEAD~2
98f1e2a HEAD@{1}: commit: Add functionality C
76d5c4b HEAD@{2}: commit: Add functionality B
a1b2c3d HEAD@{3}: commit: Project start
Aha! There they are. Look at the first line (HEAD@{0}): Git has recorded that you just did a “reset: moving to…”.
But look at the second line (HEAD@{1}): There is commit 98f1e2a with the message “Add functionality C”. The commit still exists, it’s just that no branch points to it.
Recovering the Lost Commit
Now that we have the identifier (the Hash) of the “lost” commit (98f1e2a), we can travel to it.
We can do it in two ways:
Create a new branch pointing to that commit (The recommended option):
git branch rescue-branch 98f1e2a
This creates a branch called rescue-branch that contains all your work up to commit C. Saved!
Do a reset to the future:
If you want to undo your mistake and be exactly where you were before the disaster:
git reset --hard 98f1e2a
Yes, you read that right. You used git reset to undo a git reset.
Now your HEAD points back to commit C. Your folder has the files again. The balance of the universe has been restored.
Limitations of Reflog
Although Reflog can save your (…you know…) many times, it’s not infallible. It’s more like the last resort. Some things it won’t be able to help you with:
As we said, this only records your movements on your hard drive. If you delete the repository from your hard drive, the reflog goes with it.
Git doesn’t keep garbage forever. By default, reflog entries and “orphaned” commits (that don’t belong to any branch) are deleted after a few days (usually 30 days for unreachable references, or 90 days for normal ones).
That is, if you delete a commit today, you can recover it tomorrow. But don’t try to recover it six months from now.
