Recover after an accidental git reset
Locate the old commit with a reflog or verified ORIG_HEAD, protect it with a branch, and avoid discarding surviving work during recovery.
If a reset moved your branch to the wrong commit, use the reflog to find the previous tip. First preserve surviving files and identify what you need to recover: the branch history, the index state, and uncommitted working-tree edits are different things.
Locate and protect the old commit
git reflog --date=iso
git show --stat OLD_COMMIT
git branch recovered-before-reset OLD_COMMIT
Replace OLD_COMMIT with the verified ID. If the reset was the latest HEAD movement, HEAD@{1} may be the previous tip, but subsequent commands change those offsets. ORIG_HEAD can also contain a pre-reset tip; inspect it because later operations can overwrite it.
Creating a recovery branch keeps that commit reachable without changing your current files. You can inspect it in a separate worktree if you want to compare both versions before changing the current branch.
Choose what to restore
| Previous reset | What may still remain |
|---|---|
--soft |
The index and working-tree contents were left unchanged |
--mixed |
Working-tree contents remain, but the previous index state was replaced |
--hard |
The target's tracked contents replaced the index and working tree |
If a soft reset is the only relevant operation since the mistake, a soft reset back to the verified old commit can restore the branch pointer while preserving the current index and files:
git reset --soft OLD_COMMIT
If you explicitly want the old committed snapshot and have saved current work, use this alternative:
git reset --hard OLD_COMMIT
That restores committed contents, not an arbitrary pre-reset staging arrangement or uncommitted edits. Recommitting surviving files after a soft or mixed reset can preserve their content, but it does not recreate the original commit identity and history exactly.
Recover promptly
Reflogs record reference movements in the local repository. They do not store a version of every working-tree edit, and they are not permanent backups. Expiration settings and object cleanup affect recovery independently. Establish a ref to a wanted commit while it still exists.
FAQ
What about uncommitted edits lost by a hard reset?
Look for an editor history, stash, or filesystem backup. If a file was staged earlier, its blob may still exist and git fsck can help investigate unreachable objects, but blobs do not inherently retain filenames and recovery is not guaranteed. Git cannot recover text it never stored.
What if the reflog is long?
Use timestamps, commit subjects, and the affected branch's reflog to narrow the search. Inspect candidate commits before resetting again.
Did my local reset affect the remote?
A local reset does not update server refs. A later force push can propagate the rewind. Restoring a shared branch after that requires reviewing current remote work and coordinating an explicit update; another blind force push can make the incident worse.
See git-reset, git-reflog, and git-fsck.
Contact us
Join the community
to join the community
Try Guance
Start online and pay only for what you use.
Get startedChoose a Guance plan