What cherry-pick does

git cherry-pick applies the diff of one or more commits onto the current branch as new commits. It is the right tool when you want a specific change without merging the entire branch — typical for backporting fixes to a release branch or pulling a hotfix forward.

Basic and range usage

git cherry-pick <sha>
git cherry-pick A..B          # exclusive of A, inclusive of B
git cherry-pick A^..B         # inclusive of A and B

Cherry-pick supports the same range syntax as git log. Use --no-commit (-n) to stage the changes without committing — useful when applying several picks as a single commit.

Resolving conflicts

If a pick conflicts, Git pauses. Resolve, stage, and continue:

git cherry-pick --continue
git cherry-pick --skip
git cherry-pick --abort

Recording the source

Use -x to append a "(cherry picked from commit ...)" line to the message, which auditors love:

git cherry-pick -x <sha>

Mainline for merges

Cherry-picking a merge commit is ambiguous: which parent provides the baseline? Use -m:

git cherry-pick -m 1 <merge-sha>

Mainline 1 is usually the branch that received the merge.

Pitfall: divergent histories

Cherry-picking creates a new commit with a different SHA than the original. If both branches eventually merge, Git often reconciles them, but if the two copies have diverged through later edits, you risk re-applying or conflicting. Prefer merging when whole-branch integration is desired; reserve cherry-pick for surgical extraction.

Pitfall: silent semantic drift

A textually clean cherry-pick can still break behavior if surrounding code has shifted meaning. Always run tests after picks, especially across long version gaps. Pair with "Bisect with automated test scripts" if regressions appear.

Tracking applied picks

To find which commits on a branch were cherry-picked from elsewhere, look at git log --grep="cherry picked from" when -x was used. For a more rigorous approach see git patch-id:

git log -p <sha> | git patch-id
git log -p main | git patch-id

Matching patch IDs identify equivalent changes regardless of SHA.

Common mistakes

Cherry-picking without -x on a maintained release branch makes audit trails painful. Forgetting -m on a merge commit produces an empty pick or a confusing diff. Cherry-picking a long range on top of a different base often creates conflicts that a rebase or merge would handle more cleanly. When in doubt, prefer git rebase --onto for moving sequences of commits between branches.

Related

See "Interactive rebase mastery" for restructuring picked commits, and "Maintaining a patch series with git format-patch" for an alternative workflow.