Reflog Rescue Scenarios

Reflog Rescue Scenarios

Module: Module 9: Disaster Recovery and Repository Repair

The reflog records recent movements of HEAD and branch refs. It is often the fastest way to recover after a bad reset, mistaken rebase, deleted branch, or detached HEAD experiment.

Reflog is local. It records where your refs pointed on your machine. If you lost a commit locally but it was pushed elsewhere, the remote may also have it. If it only existed locally, reflog may save you as long as garbage collection has not pruned unreachable objects.

The usual rescue move is to find the commit in git reflog, create a branch pointing at it, and inspect before merging or cherry-picking. Creating a branch is safer than immediately resetting again because it preserves the found commit under a readable name.

Command Walkthrough

git reflog --date=relative
git show HEAD@{2}
git branch rescue HEAD@{2}
git switch rescue
git log --oneline --decorate --graph --all

d4e5f6a HEAD@{0}: commit: Add focused change
a1b2c3d HEAD@{1}: checkout: moving from main to feature

Hands-on Lab

Create two commits, reset --hard back one commit, then recover the lost commit using git reflog and git branch rescue-lost-work <hash>.

What to Watch For

• Reflog is not a backup strategy. It expires and can be pruned.
• Remote repositories have their own reflog policies, often inaccessible to normal users.
• After recovery, inspect and test before integrating the rescued commit.

Completion Check

You should be able to explain what each command changed, inspect the resulting history, and describe how you would undo or recover from the operation before using it in a shared repository.