Cherry-Pick: Taking One Specific Commit

In one line

git cherry-pick copies one specific commit from anywhere in the repository onto your current branch — genuinely useful for pulling a single fix across without merging everything else around it.

0/4 · 0%

Think of it like this

Picking a single ripe cherry off a tree rather than shaking the whole branch and taking everything that falls — cherry-pick takes exactly ONE commit's changes and replays them onto your current branch, without bringing along anything else from wherever that commit originally lived.

Key ideas

01
git cherry-pick <sha> applies the exact changes from that one commit onto your CURRENT branch, creating a new commit with the same changes and message (by default) but a NEW SHA, since — like a rebased or amended commit — it now has a different parent.
02
The classic real use case: a critical bug fix lands on main, and a release/2.4 branch (already diverged from main, Phase 4.1's Git Flow) also needs that exact fix, without needing every OTHER change that's happened on main since the branches diverged — cherry-picking just that one fix commit onto the release branch is precisely the right tool.
03
Cherry-picking can conflict, exactly like a merge or rebase can — if the target branch has diverged enough that the cherry-picked commit's changes don't apply cleanly, Git pauses with conflict markers (Phase 2.2) for you to resolve by hand, then git cherry-pick --continue once resolved (or --abort to cancel entirely).
04
git cherry-pick -x <sha> appends a line to the new commit's message noting which original commit it was cherry-picked from — genuinely useful for traceability on a project where the same fix legitimately needs to exist as separate commits on multiple branches, so anyone reading history later can see the connection.
05
Cherry-picking, used heavily as a substitute for normal merging, can produce a genuinely confusing history where the 'same' change exists as multiple, differently-SHA'd commits scattered across branches — it's the right tool for the specific, occasional 'I need just this one commit elsewhere' situation, not a general substitute for merge or rebase.

Code & diagrams

CherryPickdiagram

One commit, copied onto a different branch as a brand-new commit with a new SHA.

Rendering diagram…

cherry-pick.shmarkdown

Take exactly one fix commit from main onto a release branch.

cd ~/scratch/my-first-repo

# A critical fix lands on main
git switch main
echo "critical fix" >> app.txt
git add app.txt && git commit -m "Fix critical null-check bug"
git log --oneline -1
# note this commit's short SHA, e.g. a1b2c3d

# A release branch that diverged earlier also needs JUST this fix
git switch release/1.8
git cherry-pick a1b2c3d
# the fix now exists on release/1.8 too, as a NEW commit with a new SHA

git log --oneline -1
# same message, different SHA than the original on main

# If it conflicts (the release branch has diverged enough):
# resolve the conflict markers, then:
# git add <resolved-file>
# git cherry-pick --continue
# or, to cancel entirely:
# git cherry-pick --abort

# Note the traceability with -x
git cherry-pick -x a1b2c3d
# commit message gains a line: "(cherry picked from commit a1b2c3d...)"

Explain it without notes

How is cherry-pick different from merge, given that both can bring changes from one branch onto another?

Why does a cherry-picked commit get a new SHA, even though it's meant to represent the 'same' change as the original?

Practice

Create a commit on one branch, then cherry-pick it onto a different branch, and confirm with git log that the same message now appears on both branches with two different SHAs.

Deliberately cherry-pick a commit onto a branch that will cause a conflict, resolve it by hand, and complete the cherry-pick with git cherry-pick --continue.

Trade-offs

↔
Cherry-pick is precise and genuinely useful for the specific 'I need just this one commit elsewhere' case, but leaning on it heavily as a general workflow (rather than proper branching and merging) tends to produce a history where the same logical change exists as several disconnected, differently-SHA'd commits — -x at least preserves a textual trail back to the original, but it's not a substitute for a coherent branching strategy (Phase 4.1) for anything beyond occasional, targeted fixes.

Done when you can

I can cherry-pick a specific commit from one branch onto another.
I understand why a cherry-picked commit gets a new SHA despite representing the same change.
I know how to resolve a conflict during a cherry-pick and complete or abort it.