Reflog & Recovery
Browse HEAD movement history and restore lost commits
The reflog is Git's record of every move of HEAD — commit, checkout, reset, rebase, merge, pull, cherry-pick. Git keeps it for about 90 days, which makes it the safety net for "I just reset the wrong branch". GitBor surfaces it as a browsable, restorable list.
Opening the reflog
Repository → More → Reflog… opens the full HEAD history for the current repository:
| Column | What it shows |
|---|---|
| Action | The kind of move — checkout, commit, merge, rebase, reset, pull, cherry-pick. |
| SHA | The commit HEAD pointed to. |
| Details | Git's own description of the entry. |
| Date | When it happened. |
You can Copy SHA from any entry.
Restoring
Select an entry and click Restore to hard-reset HEAD to that point (with confirmation, since uncommitted changes are lost). This is how you recover after a bad reset, an unwanted rebase, or a branch deletion — the "lost" commits are still reachable from the reflog until Git garbage-collects them.
Explaining the reflog with AI
The reflog dialog has an Explain reflog button. It turns the raw lines into a plain-language timeline: it groups low-level steps into one logical event ("you did an interactive rebase that touched 5 commits"), flags moments where HEAD moved without a commit (the recoverable "lost" commits), and suggests the exact recovery command when something looks like a mistake. See AI Helpers.
How it fits the bigger picture
The reflog is the first of GitBor's five protection layers. The others — auto-stash, save points, the operation journal and startup recovery — are described in Data Protection.