Recover after a wrong cherry-pick

What you will learn

• Understand the core purpose of Recover after a wrong cherry-pick
• Master the basic usage and common options of Recover after a wrong cherry-pick
• If the wrong commit was cherry-picked, choose reset or revert based on whether the history is already shared, then replay the correct patch sequence.
• Understand key concepts: Decision boundary
• Know when to use this feature and when to avoid it

The critical decision is whether the picked commit is already shared.

Start with a problem

You just ran a Git command and the result wasn't what you expected — maybe you even lost some commits. This has happened before, and you want a reliable set of recovery techniques.

Decision boundary

• private/local only: reset is often acceptable
• shared/public branch: prefer revert for traceable correction

Wrong picked commit

main

ABC

feature

BDE

Rollback operation

Current branch

release

AR1E'

Locate pre-pick state

git reflog
git switch -c rescue/pre-wrong-pick HEAD@{2}

Typical recovery paths

Unshared branch

git reset --hard HEAD@{2}

Shared branch

git revert <wrong-picked-commit>

Then cherry-pick the correct commit(s) in the intended order.

!Avoid hard reset on shared branches

Reset on public history shifts synchronization pain to collaborators. Revert is usually safer in team contexts.

Good follow-up reads

1. recover after reset
2. assess force-push impact
3. git-cherry-pick

Try it yourself

1. Practice the recover-after-wrong-cherry-pick command in a test repository and observe state changes before and after
2. Experiment with different options and compare the output differences
3. Simulate a real scenario where you would need to use this, and walk through the full process

Further reading

Keep going on the same topic:

• Recover after an over-aggressive reset
• Recover a deleted branch
• Recovering from a corrupted repository