Introduction

A commit that looks lost in Git is often still recoverable, especially if the problem came from reset, rebase, branch deletion, or force-push confusion. Recovery works best when you stop making destructive changes immediately, find the commit hash, and anchor it with a branch before Git has a chance to garbage-collect it.

Stabilize the Repository First

Before hunting for the commit, stop doing anything that could make recovery harder. In particular, avoid git gc, pruning commands, or additional hard resets while you are uncertain.

git status
git stash push -m "safety stash before commit recovery"

That small pause matters because “lost” in Git often means “unreferenced but still recoverable,” not “permanently deleted.”

Start With reflog

reflog is the first tool to reach for because it records where HEAD and branch references pointed over time.

git reflog --date=iso

Look for entries just before the operation that lost the commit, such as a reset, rebase, or checkout. Once you spot the relevant hash, create a recovery branch immediately.

git branch recovery/lost-commit LOST_SHA
git switch recovery/lost-commit
git show --stat LOST_SHA

Creating a branch is critical. It turns the fragile hash into a durable named reference.

Recover After an Accidental Reset

One of the most common scenarios is an accidental hard reset:

git reset --hard HEAD~3

If that removed commits you still need, reflog usually shows the previous tip. You can then restore it directly:

git reflog
git reset --hard HEAD@{1}

If you want a safer first step, branch the old state before resetting back to it.

Search Dangling Commits When reflog Is Not Enough

If the commit is no longer visible in the reflog, search unreachable objects with git fsck.

git fsck --lost-found --no-reflogs

That command may report dangling commits. Inspect them one by one:

git show CANDIDATE_SHA

When you find the right one, anchor it immediately:

git branch recovery/dangling CANDIDATE_SHA

This method is time-sensitive because unreachable objects may eventually be pruned.

Recover From Another Clone or From CI

Sometimes the commit is gone locally but still exists elsewhere. Good recovery sources include:

1. another developer’s local clone
2. CI logs that captured the old commit SHA
3. a pull request discussion or build artifact
4. a backup remote or mirror

Once you have the hash, choose the restore method based on the branch model. On a shared branch, cherry-pick is often safer:

git switch feature/payment
git cherry-pick LOST_SHA

On a private rewrite branch, resetting the branch pointer may be acceptable instead.

Verify the Recovery Before Cleaning Up

After restoring the commit, inspect both the commit history and the file changes to make sure you recovered the right thing.

git log --oneline --decorate -n 10
git diff EXPECTED_BASE..HEAD

If the commit really belongs on another branch, keep the recovery branch around until the change has been reapplied, reviewed, and verified in CI.

Prevent Future Commit Loss

A few habits make this problem much less likely:

1. push meaningful milestones before risky history edits
2. create a backup branch before major rebases
3. use --force-with-lease instead of plain --force
4. protect important branches on the server

Even a simple temporary branch can save a lot of recovery time:

git branch backup/pre-rebase-2026-03-08

Common Pitfalls

The biggest mistake is panicking and running more destructive commands before checking reflog. Another is finding the lost commit hash but forgetting to create a branch, which leaves it vulnerable again. Teams also assume a deleted branch means the commit is gone forever and stop too early without checking reflogs, dangling objects, and other clones.

Summary

• Most lost commits are recoverable if you stop destructive actions quickly.
• Start with git reflog, then use git fsck if the reflog is not enough.
• Create a recovery branch as soon as you identify the lost commit.
• Use cherry-pick for shared-branch recovery and reset for private rewrite cases.
• Build safer habits around rebases, force pushes, and backup branches to prevent repeat incidents.