Recovery

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.

Who This Is For
  • Anyone actively handling a Git mistake
  • Readers who want a conservative rescue habit before trouble happens
Prerequisites
  • Stop mutating the repo further
  • Be ready to inspect `git reflog`, `git status`, and `git log --graph`
Common Risks
  • Running more reset or rebase commands before preserving a checkpoint
  • Changing shared history before assessing blast radius

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

Decision boundary

  • private/local only: reset is often acceptable
  • shared/public branch: prefer revert for traceable correction
Recover After Wrong Cherry-pickA wrong cherry-pick can be recovered by reverting to the pre-pick state, usually via reflog or reset.
Wrong picked commit
main
ABC
feature
BDE
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