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.

Best practices
Illustration of Git branches and version history

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.

Get a tailored plan

Contact us

Join the community

Scan with WeChat
to join the community

Try Guance

Start online and pay only for what you use.

Get started

Choose a Guance plan

Code hosting