git cherry-pick: moving one commit into the current branch

git cherry-pick <hash> takes the changes of a single commit from another branch and applies them to the branch you are standing on.

The situation is a common one. The fix you need sits in somebody else's branch, and merging that branch whole is too early: half the work there is unfinished. Or an urgent fix was made on the wrong branch and has to reach main right now. Find the commit in the log and name it by hash:

$ git log --oneline redesign
fe7883f header spacing
098f8d2 fix the wrong number in the report
f8b6906 new header layout

$ git switch main
Switched to branch 'main'
$ git cherry-pick 098f8d2
[main 3472870] fix the wrong number in the report
 Date: Mon Mar 3 14:22:10 2025 +0300
 1 file changed, 1 insertion(+), 1 deletion(-)

The hash in the answer is a different one: 3472870, not 098f8d2. That is the main thing about this command. Cherry-pick does not move a commit, it writes a new commit with the same changes, its own parent and its own hash. The original stays where it was on redesign, untouched. The Date line shows that the authorship date travelled along with the changes, which is why it is not today's date.

Several commits are listed with spaces between them, and git applies them in the order you gave:

$ git cherry-pick 098f8d2 fe7883f

A range is written with two dots: git cherry-pick f8b6906..fe7883f takes everything after f8b6906 up to and including fe7883f.

When the transfer stops

If the same line has also changed in the current branch, git stops exactly the way it stops during a merge:

$ git cherry-pick 098f8d2
Auto-merging report.txt
CONFLICT (content): Merge conflict in report.txt
error: could not apply 098f8d2... fix the wrong number in the report

From there the conflict is handled the usual way: edit the file, remove the markers, put the result into the index with git add. What finishes the transfer is not git commit but a command of its own:

$ git cherry-pick --continue     # write the commit once the conflict is settled
$ git cherry-pick --abort        # call it off and go back to where you started

Common mistakes

Duplicates in the history. If redesign is going to be merged into main later anyway with git merge, the change you carried over lands there twice: once as your commit, once inside the merge. Git usually reconciles the content without a conflict, but the log keeps two similar commits with different hashes, and reading such a history is no fun. Cherry-pick is for "this one thing, right now", not a replacement for merging.

A commit torn out of its context. A change that leans on the previous commit of the same branch applies without a single complaint and leaves you with broken code: git compares text, not meaning. Look at the whole commit with git show <hash> first and check whether it drags a neighbour along.

Where this is in the book

Where those separate commits on other branches come from is covered here: Chapter 5. Branches: parallel versions of a project.