The safety net and the reflog

Why this matters

Most Git panic is unnecessary. The commands that look destructive usually only move a pointer, and Git keeps a private list of every position that pointer has held. Knowing this changes how the rest of the section reads: you are not defusing a bomb, you are looking something up.

The safety net

Every time HEAD moves, Git writes a line in the reflog: commits, checkouts, merges, resets, rebases, pulls. The commit objects themselves stay in the repository, unreferenced but intact, for about ninety days.

Three consequences, and they are the whole lesson:

• A commit you made can be found again, even after git reset --hard or deleting its branch.
• The reflog is local. It is never pushed, never fetched, and belongs to your clone alone. Your colleague's reflog cannot help you and yours cannot help them.
• Work you never committed is not in it. Git only records what it has seen.

Reading it

$ git reflog

b81702c HEAD@{0}: reset: moving to HEAD~1
d3b92ec HEAD@{1}: checkout: moving from docs/12-windows-install-steps to main
95a0014 HEAD@{2}: commit: docs: add Windows steps to installation guide (#12)
d3b92ec HEAD@{3}: checkout: moving from main to docs/12-windows-install-steps
d3b92ec HEAD@{4}: commit: chore: add CI configuration and contributing guide
b81702c HEAD@{5}: commit: docs: add getting started guide and FAQ
28593d2 HEAD@{6}: commit: feat: add the trail list command
e653def HEAD@{7}: commit (initial): chore: start the trailguide project

Read it as a diary, newest first:

So HEAD@{2} above is the moment the Windows steps commit was made. That commit is not in git log any more, because the branch was reset, but its hash is right there.

git reflog --date=relative adds "11 seconds ago" style timing, which is easier to search when you are looking for "the thing I had before lunch".

Bringing something back

$ git reset --hard HEAD@{1}

HEAD is now at d3b92ec chore: add CI configuration and contributing guide

That is the undo for a bad reset: find the line describing the state you want, and reset to it. The same works with the raw hash, which is safer to read than a counted position:

$ git reset --hard d3b92ec

Git also keeps ORIG_HEAD, a bookmark for where you were before the last big move (a reset, a merge, a rebase, a pull). When you have just done one thing wrong, it is the fastest answer:

$ git reset --hard ORIG_HEAD

A branch, not just a commit

Deleting a branch deletes a name, not the commits. Git even prints the hash as it goes:

$ git branch -D docs/12-windows-install-steps

Deleted branch docs/12-windows-install-steps (was 95a0014).

Recreating it is one command:

$ git switch -c docs/12-windows-install-steps 95a0014

Switched to a new branch 'docs/12-windows-install-steps'

If you did not note the hash, the reflog has it, and so does git fsck --lost-found, which lists commits nothing points at any more:

$ git fsck --lost-found

dangling commit 95a001407cde528f92b4c796b2e359e301e2b863

Per-branch reflogs

git reflog shows HEAD. Each branch has its own, which is often the clearer question to ask:

$ git reflog show main

d3b92ec main@{0}: reset: moving to ORIG_HEAD
28593d2 main@{1}: reset: moving to HEAD~2
d3b92ec main@{2}: reset: moving to HEAD@{1}
b81702c main@{3}: reset: moving to HEAD~1
d3b92ec main@{4}: commit: chore: add CI configuration and contributing guide
b81702c main@{5}: commit: docs: add getting started guide and FAQ

"Where was main yesterday morning?" is answered by git reflog show main, and main@{yesterday} is valid syntax for it.

What really is lost

The list is short, and every item is about work Git never recorded:

Everything else is a lookup. That is why the advice throughout this course is to commit early: a commit is the moment work becomes recoverable.

How to do it

$ git reflog
$ git reset --hard HEAD@{1}
$ git reset --hard ORIG_HEAD

Common mistakes

• Panicking and running more commands. Each one adds a reflog entry but also moves you further from the state you want. Stop and read.
• Using git reset --hard with uncommitted changes in the working tree, which throws them away as a side effect.
• Expecting the reflog to be on the server. It is yours alone.
• Assuming uncommitted work is recoverable. Only your editor's local history might have it.
• Waiting. The reflog expires; recover today, not next quarter.