Introduction

If a past commit disappeared from the current branch because someone force-pushed, reset the branch, or replaced the history, you usually do not "recreate" it by hand. The normal recovery path is to find the original commit hash and apply it again with git cherry-pick, or recover the branch position from the reflog if the whole branch history needs restoration.

Find The Missing Commit First

If you know the commit hash already, recovery is easy. If not, search for it in the log, reflog, or another clone that still has the old history.

git log --all --oneline --decorate --graph
git reflog

git reflog is especially useful when a branch tip was moved or overwritten locally, because it records where your references used to point even if normal branch history no longer shows the commit.

Reapply The Commit With cherry-pick

Once you have the hash, the most common fix is:

git cherry-pick abc1234

That creates a new commit on the current branch with the same patch content as the original commit. This is usually the safest answer when your goal is simply "put those changes back."

What If The Old Commit Was A Merge Commit

Cherry-picking a normal commit is easy. A merge commit is different because Git needs to know which parent to treat as the mainline.

git cherry-pick -m 1 <merge-commit-hash>

If you do not understand the parent structure, stop and inspect the merge first. Blindly cherry-picking merges is a good way to create confusing results.

When Reflog Is The Better Tool

Sometimes the issue is not one commit but an entire branch tip that got overwritten. In that case, reflog may let you restore the previous state directly.

1git reflog
2# find the old branch tip
3
4git checkout my-branch
5git reset --hard <old-tip>

This is powerful but destructive to the current working tree, so it is appropriate only when you intentionally want to move the branch pointer back. If you just want one lost change back, cherry-pick is usually safer.

Recovering From Another Clone Or Remote

If another developer or CI system still has the original commit, you can fetch the reference from there.

git fetch origin
git log origin/main --oneline

Even if the branch tip moved, the commit may still exist in another clone long enough to be referenced and reapplied.

Handle Conflicts Like Any Other Patch Replay

If the codebase changed since the original commit, git cherry-pick may conflict.

1git cherry-pick abc1234
2# resolve conflicts
3
4git add .
5git cherry-pick --continue

That does not mean recovery failed. It only means the old patch no longer applies cleanly to the current code.

Avoid Force-Pushing As A First Response

When someone overwrote your commit, it is tempting to fight back with another force-push. That may make the branch situation worse. In shared branches, a new commit created by cherry-pick is usually easier for the team to understand than another history rewrite.

If branch history truly must be restored, coordinate with the team first.

Common Pitfalls

The most common mistake is looking only at git log and forgetting that git reflog may still know where the lost commit was. Another is using reset --hard when all you really needed was cherry-pick, which needlessly rewrites branch state. Developers also sometimes cherry-pick a merge commit without understanding the parent selection, producing confusing changes. Finally, if the commit was already partially reintroduced elsewhere, blindly cherry-picking it again can duplicate or conflict with existing work.

Summary

• Find the missing commit hash first with git log --all or git reflog.
• Use git cherry-pick <hash> when you want the lost change back on the current branch.
• Use reflog-based branch restoration only when you intend to move the branch pointer itself.
• Expect conflicts if the codebase changed since the original commit.
• Coordinate before rewriting shared history again.