Cherry-pick

Q: Can I cherry-pick multiple commits?

Yes. List several hashes, as in git cherry-pick a1b2c3d e4f5a6b, or use a range such as git cherry-pick A..B, which applies every commit after A up to and including B.

Updated September 30, 20262 min read

In short

A cherry-pick in Git copies the changes from one specific commit onto your current branch as a new commit, without merging the rest of the branch it came from.

What is a cherry-pick in Git?

Cherry-picking lets you take a single commit from anywhere in your repository and apply it to the branch you're on. Git works out what that commit changed and creates a new commit with the same changes and message on your current branch. The rest of the source branch is left untouched.

A common use is backporting a fix. Suppose a bug fix was committed on main, and you also need it on a release/2.1 branch that is already in production: you switch to the release branch and run git cherry-pick with the fix's commit hash. It is also handy for rescuing a commit made on the wrong branch or for taking one finished change out of an unfinished feature branch.

Cherry-picking is like copying one recipe from a friend's cookbook into your own, rather than taking the whole book. The copied commit is a new commit with a new hash, even though its changes are identical. If the surrounding code differs between the branches, the cherry-pick can produce a merge conflict, which you resolve as usual and then finish with git cherry-pick --continue.

Cherry-pick differs from merge and rebase, which bring in a whole series of commits. Overusing it can leave the same change existing as several different commits across branches, which makes history harder to follow and can cause confusing conflicts later. Many teams reserve cherry-picking for hotfixes and backports, and add the -x option so the new commit message records which commit it was copied from.

Key takeaways

git cherry-pick <hash> applies one commit's changes to the current branch.
It creates a new commit with a new hash rather than moving the original.
It is commonly used to backport fixes to release branches or move a misplaced commit.
Conflicts are resolved like merge conflicts, then finished with git cherry-pick --continue.
Use it sparingly; merges and rebases are better for bringing in whole branches.

Example

Backporting a fix with cherry-pickbash

# Find the hash of the commit you want to copy
git log --oneline main
# a1b2c3d Fix crash when the cart is empty

# Switch to the branch that also needs the fix
git switch release/2.1

# Apply that one commit here (-x notes the original hash in the message)
git cherry-pick -x a1b2c3d

# If there's a conflict: fix the files, stage them, and continue
git add src/cart.ts
git cherry-pick --continue   # or: git cherry-pick --abort

Readers ask

What is the difference between cherry-pick and merge?

Merge brings every commit from another branch into yours. Cherry-pick copies only the specific commits you choose, creating new commits on your branch.

Can I cherry-pick multiple commits?

Yes. List several hashes, as in git cherry-pick a1b2c3d e4f5a6b, or use a range such as git cherry-pick A..B, which applies every commit after A up to and including B.

Is cherry-picking bad practice?

Not in itself, but it should be used deliberately. Cherry-picking the same change onto many branches duplicates commits and can make history and future merges confusing, so it works best for targeted cases like hotfixes and backports.