Cherry-picking — taking one specific commit, not a whole branch

Merge and rebase both bring over an entire branch's worth of commits. Cherry-pick is for the narrower, genuinely common case of wanting exactly one specific commit from somewhere else, without anything around it.

Intermediate

3 min read

The situation cherry-pick fits: one commit, not a whole branch

feature-a:  A -- B -- C -- D
                       \
                        (C is a critical bug fix; B and D are unrelated,
                         unfinished work you don't want on main yet)

Merging or rebasing feature-a into main would bring over B, C, and D together — but only C, the critical bug fix, is actually wanted on main right now. This is exactly the situation git cherry-pick is built for: taking one specific commit's changes and applying them elsewhere, without pulling in anything else from the branch it came from.

`git cherry-pick`: applying one commit's changes as a new commit

git checkout main
git cherry-pick C

main:  A -- B -- C'   (C's changes, applied as a new commit on main)

git cherry-pick, given a commit hash, takes the changes introduced by that one commit and applies them as a brand-new commit on the current branch — the content matches the original commit, but (the same way rebase produces new hashes) it becomes a genuinely new commit object, with its own hash, since it now has a different parent than the original did. feature-a is completely unaffected — cherry-pick reads from it, it doesn't modify it.

Why cherry-pick can hit the same kind of conflict a merge can

$ git cherry-pick C
error: could not apply C... Fix critical bug
Conflict markers left in the affected file(s)

Cherry-pick applies a commit's changes as a diff against the current branch's code — if the current branch has diverged enough that the same lines the cherry-picked commit touches have also changed here, a conflict results, resolved exactly the same way a merge conflict is (from the branching lesson): edit the file to resolve it, then git add the resolved file and git cherry-pick --continue.

The real cost: the same logical change can end up with two different histories

feature-a:  ... -- C (original) -- ...
main:       ... -- C' (cherry-picked copy, same content, different hash) -- ...

Because cherry-pick creates a new commit rather than moving the original, the same logical change now exists as two separate commit objects with different hashes — C on feature-a, C' on main. If feature-a is later merged into main too, Git generally handles this correctly (it can often recognize the content is equivalent and avoid a duplicate), but it's a real source of confusion if someone's later trying to trace "where did this change actually come from" and finds it in two different places with two different hashes.

When cherry-pick is genuinely the right tool

Good fit:  a critical hotfix committed on a feature branch needs to go
           to main immediately, without waiting for the rest of that
           branch's unfinished work

Poor fit:  regularly cherry-picking many commits between branches as a
           substitute for actually merging — this usually signals the
           branch structure itself should be reconsidered

Cherry-pick earns its keep for the genuinely narrow, occasional case: one specific commit needs to exist somewhere it wasn't originally made, right now, without its neighbors. Reaching for it repeatedly as a general way to move work between branches is usually a sign that the underlying branching strategy doesn't actually fit how the work is organized — at that point, restructuring how branches are used is a better fix than habitually cherry-picking around the mismatch.