The reflog — your actual safety net

The undoing-changes lesson called reset --hard's discarded changes unrecoverable "through ordinary means." The reflog is the extraordinary means — a local, private log of everywhere HEAD has pointed, that makes most Git mistakes genuinely recoverable.

Intermediate

4 min read

What the reflog actually is: a log of where HEAD has been

git reflog

a3f8e21 HEAD@{0}: reset: moving to HEAD~1
9c2d104 HEAD@{1}: commit: Add login validation
7b1a880 HEAD@{2}: checkout: moving from main to feature-login
...

Git keeps a private, local record of every place HEAD (the current commit reference) has pointed, in order — every commit, checkout, reset, rebase, and merge leaves an entry. This is genuinely separate from the commit history git log shows: log shows the project's actual structure of commits; reflog shows the sequence of actions this local repository actually took, including ones that later got undone or overwritten.

Why this matters: it remembers commits that "disappeared"

$ git reset --hard HEAD~3     # per the undoing-changes lesson, this discards 3 commits...
$ git log --oneline            # ...and they're genuinely gone from `log`'s view

$ git reflog                    # but the reflog still remembers exactly where HEAD was before
9c2d104 HEAD@{1}: commit: Add login validation   <- this commit still physically exists

The undoing-changes lesson described reset --hard as discarding changes "with no recovery through ordinary means" — the reflog is the extraordinary means. The commits themselves aren't actually deleted the instant reset --hard runs; they become unreachable from any branch, but Git doesn't garbage-collect them immediately. The reflog still has a record of the exact hash they lived at, which is enough to get them back.

The actual recovery: `git reset` (or `checkout`) to a reflog entry

git reflog
# 9c2d104 HEAD@{1}: commit: Add login validation

git reset --hard 9c2d104        # HEAD (and the branch) moves back to that exact commit

Once the reflog reveals the hash of a commit that seemed to vanish, running git reset --hard with that hash moves the current branch back to point at it directly — effectively undoing the mistake that caused it to become unreachable in the first place. This is the standard, real recovery procedure for "I ran the wrong reset command" or "I force-pushed and lost commits" — check the reflog, find the last-known-good hash, reset to it.

Why this is genuinely a safety net, not a guarantee

Commits unreachable from any branch/tag, with no reflog entry pointing to them,
get cleaned up eventually by `git gc` (garbage collection) — normally after
about 30 days, though this is configurable

The reflog isn't permanent, and it isn't shared — it's local to one machine's copy of the repository, and entries eventually expire (Git periodically runs garbage collection that removes commits with no remaining reference, including old reflog entries, typically after about 30 days by default). This is why the reflog is a genuine safety net for recent mistakes, not an infinite undo history — the sooner a mistake is noticed and the reflog checked, the more certain the affected commits are still recoverable.

Why "local only" makes the reflog different from everything else in this domain

Commits, branches, tags -> can be pushed, shared, pulled by others
Reflog                   -> exists only on this one local repository, never pushed or shared

Every other Git concept covered so far (commits, branches, tags) can move between repositories via push and pull. The reflog specifically never does — it's a purely local record of what this copy of the repository actually did, which is exactly why it can help recover from a local mistake (a bad reset, an accidental branch deletion) but can't help at all if the actual problem is that commits were lost from a remote that a different reflog, on a different machine, would need to track instead.

The practical habit this lesson is really teaching

Made a Git mistake? Before panicking or trying to manually reconstruct
lost work:
1. git reflog
2. Find the entry from right before the mistake
3. git reset --hard to that hash

Knowing the reflog exists is what turns a genuinely alarming Git mistake — "I think I just deleted three days of work" — into a routine, three-step recovery instead. This is worth internalizing specifically because the moment it's needed is exactly the moment panic makes people reach for something destructive instead of something safe — checking the reflog first is almost always the right first move before doing anything else.