How to use git cherry-pick

git cherry-pick takes the changes introduced by an existing commit and replays them as a new commit on your current branch. It is the standard tool for backporting bug fixes from main to a release branch, lifting one fix out of a long-lived feature branch, or pulling a single commit forward when a full merge isn't appropriate.

The new commit has a different SHA than the original — cherry-pick copies changes, it does not move commits.

Basic usage

git switch release/1.2
git cherry-pick <sha>

The commit identified by <sha> is applied on top of release/1.2 as a new commit, with the same author, message, and changes.

You can pass any object git can resolve:

git cherry-pick a1b2c3d
git cherry-pick main
git cherry-pick origin/feature/x~2

Cherry-pick a range of commits

git cherry-pick A..B

This applies every commit after A up to and including B, in order. Note: A..B is exclusive of A — if you want to include A, use:

git cherry-pick A^..B

Tip: a range is just shorthand. You can also list commits explicitly, which is often clearer:

git cherry-pick a1b2c3 d4e5f6 7g8h9i

Useful flags

git cherry-pick -x <sha>           # append "(cherry picked from commit ...)" to the message
git cherry-pick --no-commit <sha>  # apply changes but don't commit (alias: -n)
git cherry-pick --edit <sha>       # apply, then open the message in your editor
git cherry-pick --signoff <sha>    # add a Signed-off-by trailer
git cherry-pick -m 1 <merge-sha>   # cherry-pick a merge commit, keeping parent 1

-x is highly recommended for backports — it leaves an audit trail in the message of where the change originally came from.

-n is useful when you want to review or combine multiple cherry-picks into one commit:

git cherry-pick -n a1b2c3 d4e5f6
git diff --staged    # review
git commit -m "Backport fixes for issue #42"

Handling conflicts

If a cherry-pick conflicts, git stops and tells you which files conflict — same as a merge. Resolve the markers, stage the files, then continue:

# edit conflicted files
git add path/to/file
git cherry-pick --continue

If you decide partway through that you don't want this commit after all:

git cherry-pick --abort

To skip the current commit (in a multi-commit cherry-pick) and move on to the next:

git cherry-pick --skip

Cherry-picking a merge commit

A merge commit has two parents. Cherry-pick needs to know which side of the merge to treat as "the change" — pass -m <parent-number> (almost always -m 1):

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

-m 1 says "the change is the diff from parent 1 (mainline) to the merge". Without -m, git refuses to cherry-pick a merge.

Practical recipes

Backport a hotfix from main to a release branch

git switch release/1.2
git cherry-pick -x main~0
git push

Lift one commit out of a long-running branch

You're on feature/big-rewrite and you want to push a small unrelated cleanup commit to main now.

git switch main
git cherry-pick -x feature/big-rewrite~3
git push

Combine several cherry-picks into one commit

git cherry-pick -n a1b2c3 d4e5f6 7g8h9i
git commit -m "Backport: navigation bar fixes"

Cherry-pick from a remote branch you haven't checked out

git fetch origin
git cherry-pick -x origin/feature/x~1

When cherry-pick is the wrong tool

Cherry-pick is a sharp instrument. Reach for something else when:

You want every commit from one branch on another. Use git merge or git rebase. Repeated cherry-picks of the same commits will eventually conflict with a real merge.
You're trying to preserve history. Cherry-picked commits get a new SHA, so tools that follow merges (e.g., git log --first-parent) won't see them as the same.
The commit depends on earlier commits not present on the target branch. You'll either fail with conflicts or successfully apply something that doesn't compile. Pick the prerequisite commits too, or rebase the whole feature branch.

Pitfalls

Duplicate commits. A cherry-picked commit and the original have different SHAs but the same patch. If you later merge the source branch, git is usually smart enough to notice and not apply it twice — but the commit message will appear twice in git log unless you use -x and squash carefully.
The range syntax is exclusive of the start. git cherry-pick A..B does not include A. Use A^..B to include it.
Empty commits. If the changes are already present on the target (e.g., a previous cherry-pick), git stops with --allow-empty advice. Add --allow-empty to keep an empty commit, or --skip to drop it.
Cherry-picking a merge requires -m. Forgetting -m 1 is the most common error when backporting.

Summary

git cherry-pick <sha> copies a commit's changes to your current branch as a new commit.
Use -x for backports — it documents the origin in the commit message.
Resolve conflicts then --continue; bail out with --abort.
For merge commits, use -m 1.
If you need many commits, prefer merge or rebase — cherry-pick is for surgical work.