Git Cherry-Pick

Overview

git cherry-pick copies the change introduced by one or more existing commits and reapplies them as new commits on your current branch. It is ideal for backporting a bug fix to a release branch or grabbing a single commit without merging an entire branch. Because it creates new commit SHAs, avoid cherry-picking commits that will later be merged normally to prevent duplicates.

Syntax / Usage

Pick a commit by its hash, or a range, and Git replays it onto HEAD.

# Apply a single commit onto the current branch
git cherry-pick a1b2c3d

# Apply several commits in order
git cherry-pick a1b2c3d e4f5g6h

# Apply a contiguous range (exclusive of the first)
git cherry-pick main~4..main~1

# Stage the change but do not commit yet
git cherry-pick --no-commit a1b2c3d

Examples

Backport a fix from main onto a maintenance branch:

git switch release/2.x
git cherry-pick 9f8e7d6
git push origin release/2.x

Resolve a conflict mid-cherry-pick, then continue or abort:

git cherry-pick 9f8e7d6
# fix conflicts in the reported files
git add fixed-file.ts
git cherry-pick --continue
# or bail out entirely
git cherry-pick --abort

Record where the commit came from for traceability:

git cherry-pick -x 9f8e7d6
# appends "(cherry picked from commit 9f8e7d6)" to the message

Common Mistakes

• Cherry-picking commits that will also be merged, creating duplicate changes
• Forgetting --continue after resolving conflicts, leaving the pick unfinished
• Picking a merge commit without -m to specify the mainline parent
• Assuming dependencies come along—picking a fix but not the commit it relies on
• Losing provenance by omitting -x when backporting across branches

See Also

commit branch merge