Git Reflog: Recovering Lost Commits and Fixing Mistakes

Losing commits or branches due to Git operations like reset, rebase, or branch deletion can be frustrating. Fortunately, Git maintains a detailed log of reference changes called the reflog, which serves as a safety net for recovering lost work.

This article explains:

• How the reflog works

• Practical scenarios for recovering commits

• Limitations of the reflog

Understanding the Reflog

The reference log (reflog) records all changes to Git references (branches, HEAD) in your local repository. Unlike the commit history, which is shared across clones, the reflog is local and temporary (typically retained for 90 days).

Key properties:

• Tracks every commit, checkout, merge, rebase, and reset operation

• Each entry includes a commit hash, action, and timestamp

• Accessed via git reflog or inspecting .git/logs/

Common Recovery Scenarios

1. Restoring After a Hard Reset

If you ran:

git reset --hard HEAD~1  # Discards the last commit

Recovery steps:

1. Identify the lost commit:

    git reflog
   

   Example output:

    a1b2c3d HEAD@{0}: reset: moving to HEAD~1  
    e4f5g6h HEAD@{1}: commit: Implement user authentication
   

2. Restore the commit to a new branch:

    git checkout -b recovered-branch e4f5g6h
   

2. Recovering a Deleted Branch

After deleting a branch:

git branch -D feature/login

Recovery steps:

1. Locate the branch's final commit:

    git reflog --all | grep 'feature/login'
   

2. Recreate the branch:

    git branch feature/login e4f5g6h
   

3. Fixing a Failed Rebase or Merge

If a rebase introduced conflicts or errors:

1. Find the pre-rebase state:

    git reflog
   

2. Reset to the stable commit:

    git reset --hard HEAD@{2}
   

Technical Notes

How the Reflog Works

• Entries are stored in .git/logs/HEAD and .git/logs/refs/heads/<branch>

• HEAD@{n} syntax refers to the nth prior position of HEAD

• Timestamps use the format HEAD@{5.minutes.ago}

Limitations

• Local only: Not shared via push/pull

• Temporal: Entries expire (~90 days by default)

• No unstaged changes: Only tracks committed states

Best Practices

1. Verify before destructive operations
   Use --dry-run with reset or prune to preview changes.

2. Document important hashes
   Note commit hashes before complex operations like interactive rebases.

3. Combine with fsck for orphaned commits

    git fsck --lost-found
   

Reference Commands

Conclusion

The reflog is an essential tool for recovering from Git mishaps. By understanding how to:

• Locate lost commits

• Restore deleted branches

• Revert failed operations

developers can work with confidence, knowing mistakes are recoverable. For team workflows, consider supplementing with remote backups or tags for critical commits.