Git Cherry-Pick Explained

Quick Answer

git cherry-pick takes the changes from one specific commit and replays them as a new commit on your current branch, without bringing in the rest of that branch's history. It's the right tool for grabbing a single bug fix or feature commit from one branch onto another. If the target branch has changed the same lines, cherry-pick stops and asks you to resolve a conflict just like a merge would.

What Cherry-Pick Actually Does

git cherry-pick takes the diff introduced by one specific commit and applies it as a brand new commit on whichever branch you currently have checked out. The content is copied, but the commit itself is not moved: the original stays exactly where it was, and the new commit gets its own commit object even when the changes and message match exactly.

This is different from merge, which brings in an entire branch's history and creates a merge commit joining the two, and different from rebase, which replays a whole sequence of commits at once. Cherry-pick is for grabbing one commit, no more, no less.

The classic use case: a bug fix lands on your develop branch, and it also needs to ship in the already-released v2.1 branch right away, without dragging in every other change that has piled up on develop since the release branched off. You cherry-pick just that one commit onto v2.1, tag it, and ship.

A Clean Cherry-Pick, Start to Finish

Here's a real run, not a paraphrase. Starting from a main branch with one commit, a feature branch is created and gets a commit adding a new file:

$ git checkout -b feature
$ echo "New feature file" > newfile.txt
$ git add newfile.txt
$ git commit -m "Add newfile.txt"
[feature 50c9865] Add newfile.txt

Back on main, cherry-picking that exact commit:

$ git checkout main
$ git cherry-pick 50c9865
[main 50c9865] Add newfile.txt
 Date: Fri Sep 11 08:58:12 2026 +0530
 1 file changed, 1 insertion(+)
 create mode 100644 newfile.txt

The file and the message are now on main, with no trace of the rest of feature's history. That's a clean cherry-pick: no conflicts, no drama. (Notice the commit hash stayed 50c9865 on both branches here, which isn't the usual outcome, more on that below.)

When Cherry-Pick Conflicts

Cherry-pick conflicts exactly like a merge does, when the change it's replaying touches a line the target branch has already changed. Here's a genuine one: main and feature each edit the same line of file.txt, but to different text.

$ git checkout main
$ echo "hello from main" > file.txt
$ git commit -am "Update file.txt on main"
[main 044b45e] Update file.txt on main

$ git checkout feature
$ echo "hello from feature" > file.txt
$ git commit -am "Update file.txt on feature"
[feature 13bb1d8] Update file.txt on feature

Cherry-picking the feature commit onto main:

$ git checkout main
$ git cherry-pick 13bb1d8
Auto-merging file.txt
CONFLICT (content): Merge conflict in file.txt
error: could not apply 13bb1d8... Update file.txt on feature
hint: After resolving the conflicts, mark them with
hint: "git add/rm <pathspec>", then run
hint: "git cherry-pick --continue".

Git stops mid-operation. The working directory now holds a half-finished cherry-pick, and file.txt contains real conflict markers.

Resolving It and Continuing

Opening file.txt shows exactly what you'd expect from a merge conflict:

<<<<<<< HEAD
hello from main
=======
hello from feature
>>>>>>> 13bb1d8 (Update file.txt on feature)

git status confirms the state and spells out the next steps:

On branch main
You are currently cherry-picking commit 13bb1d8.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   file.txt

Edit the file to the resolution you actually want, stage it, and tell Git the cherry-pick is done:

$ echo "hello from main and feature" > file.txt
$ git add file.txt
$ git cherry-pick --continue

That opens the commit message editor pre-filled with the original message; save it and the cherry-pick finishes as a new commit on main. Change your mind instead, and git cherry-pick --abort puts everything back exactly as it was before you started.

Gotchas Worth Knowing

A few things that catch people out:

• The SHA usually changes, but not always. In the clean example above, the cherry-picked commit landed on main with the identical hash 50c9865 it had on feature, because the tree, the parent commit, and even the timestamp (Git stores second-level precision) all matched exactly. That's a coincidence of an unmoved base branch, not a rule. The moment either branch has diverged further, the parent differs and you get a new SHA with the same content.
• Merge commits need -m. git cherry-pick on a merge commit's SHA fails outright unless you specify which parent's diff to use, for example git cherry-pick -m 1 <sha>.
• Cherry-picking a range with git cherry-pick A..B applies every commit from A, exclusive, through B, inclusive, in order. If commit three of five conflicts, the rest wait until you resolve and continue.
• It duplicates history. If that same change later gets merged normally too, Git usually recognizes the content is identical and skips it, but it's worth checking rather than assuming.

Frequently Asked Questions