Your Personal Time Machine: The Git Reflog
We've all been there. You run a git rebase that goes horribly wrong, or you accidentally delete a branch you still needed. In a moment of panic, you think you've lost your work forever.
But what if I told you Git has a secret safety net? A personal log of every single move you make?
Meet the reflog.
The reflog is a private record of where your HEAD and branch pointers have been for the last 90 days. Every time you commit, merge, rebase, or switch branches, Git records it. It's your local, personal history of everything you've done, and it's your ticket to undoing almost any mistake.
To see it in action, just run:
git reflogYou'll be presented with a reverse-chronological list of events that happened in your local repository.
93fbb13 (HEAD -> feature/GG-2_deploymentTooling) HEAD@{0}: commit: task(deployment): some stuff
d7e56ba HEAD@{1}: commit: task(deployment): fixing issues
33246f4 HEAD@{2}: pull origin feature/doc: Merge made by the 'ort' strategy.
783d150 HEAD@{3}: commit: task(deployment): cleanup
2bcb935 HEAD@{4}: commit: task(deployment): Added pipeline
ce2bee3 HEAD@{5}: commit: task(deployment): init script
0dfcf77 HEAD@{6}: checkout: moving from main to feature/GG-2_deploymentToolingWhat if I told you that you could use it to go back in time to any of these states and get your repository, commits, and files back to how they were?
Great Scott!
Let's look back at our reflog. See those HEAD@{x} references? These are floating pointers to any previous state of your repository. When you execute a command, the current state is pushed down the list (FILO-style). You'll want to use the commit hash next to it.
It can be a bit hard to read sometimes, but you only need to pinpoint the moment you made a mistake and then use the state "just before it" to anchor yourself.
Let's say I messed up earlier and wanted to rebase, not merge, and I want to go back to right before I pulled. I can see the reference to my "pull" action is 33246f4 HEAD@{2}. But I actually want to go back just before that, so I'll use 783d150 HEAD@{3}. I just have to reset back to it:
git reset --hard 783d150And just like that, my branch is exactly as it was when I made the task(deployment): cleanup commit:
$> git log
commit 783d1503f9054440912c3df1d73f8242fe682966 (HEAD -> feature/GG-2_deploymentTooling)
Author: Mickaël Forgh <mickael.forgh@git-gud.com>
Date: Mon Oct 27 22:34:11 2025 +0100
task(deployment): cleanup
commit 2bcb935549942b197bb331c48b348a6b7362f2c0
Author: Mickaël Forgh <mickael.forgh@git-gud.com>
Date: Mon Oct 27 22:34:00 2025 +0100
task(deployment): Added pipeline
commit ce2bee3f1d853ca9d9e5d546f6560fde6b2b4704
Author: Mickaël Forgh <mickael.forgh@git-gud.com>
Date: Mon Oct 27 22:33:46 2025 +0100
task(deployment): init script
commit 0dfcf7771114be2daff46ddc9218f3605cd04398
Author: Mickaël Forgh <mickael.forgh@git-gud.com>
Date: Wed Oct 1 02:57:13 2025 +0200
feat(doc): workflow big picture and feature branchBy the way, the reset you just performed was also added to the reflog. So if you ever regret your time travel and want to go "back to the future," you can just use the reflog to find the state you were in before the reset.
Current branch
Beware, reset --hard will change the commits on your current branch to match the state you're resetting to, but it won't change which branch you're on. So if you were on main and did a hard reset to a commit from a feature branch, you'd get the commits from your feature branch... but you'd still be on main.
Always commit your changes
This technique will only help you revert to a state that was previously committed. It won't retrieve a file you never bothered to commit. So commit frequently!