Disaster Recovery with Reflog

The panic moment — a branch deleted, a rebase gone wrong, a reset --hard on the wrong branch — is almost never the disaster it feels like. Git wrote down everywhere HEAD has been, and the way back is usually two commands.

Why This Module Matters

Every Git user has one story: the afternoon they thought they had destroyed a day of work. Most of those stories end with someone senior leaning over, typing git reflog, and quietly restoring everything.

The mechanism is simple. Every time HEAD moves — a commit, a checkout, a merge, a rebase step, a reset — Git appends a line to a local log with the commit ID it moved from. Commits that no branch points to any more are still in the object database, and the reflog still knows their IDs. Nothing is unreachable while its ID is written down somewhere.

That is why this module belongs immediately after the undo mechanics one. reset --hard is a dangerous command right up until you know the reflog exists, at which point it becomes a recoverable one.

The one genuine limit is worth learning properly: the reflog is local, it is not pushed, and its entries expire. Recovery works on the machine where the mistake happened, and it works within a window, not forever.

What You'll Learn

• What the reflog records, where it lives, and why it is per-clone rather than shared
• Reading git reflog output: the HEAD@{n} syntax and what each action name means
• Recovering a commit orphaned by a bad reset --hard
• Recovering a branch after git branch -D, with git reflog and git branch <name> <sha>
• Undoing a rebase in one move with git reset --hard ORIG_HEAD
• Expiry, git fsck --lost-found, and when a thing really is gone

Pro Tip

The instant you realise you have made a mistake, stop and run git reflog before doing anything else. Every further command adds noise to the top of the log, and a few of them can expire what you were about to recover.