Git reflog records local reference updates that can help locate commits after a reset, rebase or branch movement. Inspect the candidate and preserve it with a new branch before changing your current branch. This guide explains a cautious recovery workflow and why reflogs do not guarantee recovery of uncommitted files or expired objects.
The safest workflow is to stop destructive changes, inspect the available evidence, and create a new reference to the candidate commit before altering your working branch. This guide focuses on recovering your own local repository without rewriting shared history prematurely.
Git reflog recovery: preserve current work before investigating
Before trying a fix, inspect the working tree and identify modifications that have not been committed. Copy important files through an appropriate local backup process if necessary. Another hard reset can destroy work you still have, even while you are trying to restore an older commit.
Record the current branch, HEAD commit, and relevant recent commands. Do not run aggressive cleanup or expiration commands while investigating. Recovery depends on the objects and references still available in this repository, so reducing that evidence is the opposite of progress.
If the repository is important, preserve a copy using a method that includes the Git data and relevant working files. Consider access permissions and secrets before placing that copy on shared storage. A recovery backup must not become an accidental source-code disclosure.
Read the local reference history
Start with nonmutating inspection:
git status
git reflog show HEAD
git log --oneline --decorate -n 12HEAD’s reflog commonly shows branch switches, resets, commits, and rebases. Branch references may have their own reflogs. Read the messages and timestamps as clues, then examine candidate commits rather than assuming the most recent previous entry is always the desired state.
Reflogs are local. A teammate’s clone does not automatically contain your reference movement history. A fresh clone of the remote also does not recreate everything you did locally. If a useful commit was never pushed, recovery may depend on the original repository that still holds it.
Inspect a candidate before choosing it
Use the candidate’s object ID with commands such as git show or git log. Review changed files, parent relationships, and commit content. A descriptive commit message is helpful, but it does not establish that this is the exact version you need.
During a rebase, related commits can exist under new IDs because their parent relationship changed. Distinguish the pre-rebase state from the rewritten result. Compare content and sequence, not only identifiers. You may want one missing change rather than the entire old branch topology.
If investigation needs a working copy, use a separate worktree or another deliberate inspection method. Avoid repeatedly checking out uncertain commits on top of uncommitted work. Keep the current project state and the recovery experiment clearly separated.
Create a recovery reference first
Once you identify a useful commit, make it reachable through a new branch name before changing the original branch. For example, replace the placeholder below with the reviewed object ID:
git branch recovery-reviewed <candidate-commit>This does not switch the working tree. It gives the commit a normal reference that you can inspect and use later. Choose a unique name and verify the new branch points to the intended commit. If a similarly named branch already exists, do not overwrite it casually.
Preserving the candidate reduces reliance on an expiring reflog entry. It also gives you time to decide whether to cherry-pick a change, merge a recovery branch, or restore a private branch. Those choices have different consequences for history and collaboration.
Choose restoration based on collaboration
For a private branch, resetting to a reviewed commit may be appropriate after protecting any current work. For a branch others use, replacing its history can disrupt their work. Coordinate before force-pushing or moving a shared reference, even when you are confident you found the lost state.
Often the best repair is to apply a missing commit or create a new corrective commit rather than replacing the entire branch. Review conflicts carefully and run tests. Recovery restores a historical input; it does not establish that the input still works with today’s dependencies and surrounding code.
If you must publish a recovery change, confirm the target remote and branch. Do not use a generic force-push as the first step of an investigation. Treat server-side protections and the team’s history policy as requirements, not obstacles to bypass.
Understand expiration and missing objects
Git documents configurable expiration for reflog entries, with different defaults for reachable and unreachable history. Garbage collection can eventually remove objects that no longer have the required reachability. The exact opportunity for recovery depends on repository configuration and maintenance history.
Do not assume that an entry from months ago will still resolve. Conversely, the absence of a convenient reflog entry does not prove no useful object exists anywhere. Other branches, tags, stashes, backups, or a collaborator’s repository may preserve the change.
Recovery of uncommitted files is a separate question. Reflogs describe reference movements, not a complete timeline of every working-tree edit. Previously committed, staged, or stashed material can have different recovery possibilities, but a never-recorded file change should not be promised as recoverable through reflog alone.
Practice on a disposable repository
Create a small test repository with two simple commits. Move a private branch backward in the test, inspect the reflog, identify the later commit, and create a recovery branch. Compare the file content before deciding which restoration method you would use.
Then repeat a scenario with an uncommitted edit and observe what the reflog does not record. This separates useful commit recovery from unrealistic expectations about working-tree preservation. Keep all destructive practice inside a disposable directory, never inside a project you are currently trying to rescue.
Document a team runbook with safe inspection commands, preservation steps, and a shared-history approval route. The best time to learn the distinctions between reset, revert, cherry-pick, and recovery branches is before an urgent production fix depends on them.
Recover a commit after reset without another destructive reset
First preserve any current uncommitted work. Then inspect the relevant local reflog and examine candidate commits with git show or git log. A message near the time of the reset is a clue, not proof that a candidate contains the wanted changes.
Once you have verified a candidate, use the recovery-branch command shown earlier in this guide with its actual commit ID. This adds a reference without moving your working branch or overwriting its files. Review the recovered tree before choosing a separate checkout, a cherry-pick or another coordinated integration method.
Reflogs are local and subject to expiration, and objects can be pruned. A remote host does not automatically provide your local reflog. Avoid cleanup or garbage-collection experiments during recovery, and do not promise that a reflog can recreate file edits that were never preserved in a commit or another recoverable object.
Frequently asked questions
Is the reflog copied by a normal clone?
No. Reflogs track local reference updates. A new clone does not reproduce your machine’s local activity history.
Should I immediately reset to HEAD at its previous entry?
No. Inspect the candidate, protect current work, and create a recovery reference first. The prior entry may not represent the state you intend to restore.
Where can I check exact retention behavior?
Read the Git reflog documentation. For inspecting a candidate without disturbing your active checkout, see our Git worktrees guide.
