■ the answer first

git cherry-pick <sha> copies one commit — same patch, new SHA, nothing moved.

A range excludes its start: A^..B includes A, A..B silently skips it.

Stopped on a conflict? Resolve, git add, git cherry-pick --continue — until then you are mid-sequence.

THE COPY, DRAWN

One fix living on a feature branch; main needs it now. The pick replays the patch, mints a new SHA, and leaves the original exactly where it was:

fig — copy, not move: delete the feature branch whenever you like; the picked copy has its own SHA and no dependency on the old one

THE THREE STEPS

Find the SHA, switch to the target branch, pick — the pick lands wherever HEAD points:

# 1. locate the commit on the source branch
git log feature/payment-fix --oneline -5

# 2. switch to the branch that should receive it
git switch main

# 3. copy it over
git cherry-pick 1a2b3c4

verify: git log -1 --stat → the picked change, new SHA, on the target branch

Two conveniences worth knowing: git cherry-pick <branch> picks that branch's tip commit — handy, but easy to do by accident with a stale mental model of what "the tip" is. And after any pick, git log -1 --stat confirms what landed: one second of reading, saves a revert.

MULTIPLE COMMITS

Three shapes, in order of how often you want them — all work across branches, since SHAs resolve against the whole repository:

# 1. explicit list — picked in the order you list them
git cherry-pick 1a2b3c4 5d6e7f8

# 2. range — everything after A up to and including B
git cherry-pick A..B

# 3. range including A
git cherry-pick A^..B

verify: git log --oneline -4 after the pick → both commits replayed in order, oldest first

The A..B vs A^..B distinction is the classic surprise: A..B excludes A. Visualize the range from git log, pick oldest..newest, and you silently skip the oldest commit — oldest^..newest makes the off-by-one disappear. To fold several picks into one commit instead of three, stage without committing using -n / --no-commit, then commit once:

git cherry-pick -n 1a2b3c4 5d6e7f8
git commit -m "Backport: payment retry fixes"

"WHY ISN'T IT WORKING" — THE FOUR CAUSES

  1. A conflict stopped the pick. Git applies the patch, hits a line that changed on both branches, and pauses mid-sequence. Resolve the files, then git add <resolved-files> and git cherry-pick --continue — or --abort to return to the pre-pick state. --continue is not optional and not implied: until you run it, git status keeps saying You are currently cherry-picking.
  2. The pick is empty ("The previous cherry-pick is now empty") — the change already exists on this branch, often from an earlier pick or a squashed merge. Skip it with git cherry-pick --skip, or force an empty marker with --allow-empty.
  3. The commit is a merge commit. A merge has two parents, so "apply this diff" is ambiguous — git refuses rather than guess. Say which parent you are diffing against: git cherry-pick -m 1 <merge-sha>. Parents are numbered in the order git recorded them: parent 1 is the branch you were on when you merged, parent 2 is the branch that came in — -m 1 is almost always what a backport wants.
  4. Wrong working tree or detached HEAD. The pick lands wherever HEAD points. git branch --show-current before picking; if it prints nothing, you are in detached HEAD and the commit will be orphaned when you switch away.

PICK VS MERGE VS REBASE

CommandWhat lands on the targetHistoryUse when
git cherry-pick <sha>Named commit(s) onlyCopy, new SHAsOne specific fix must move now
git merge <branch>Everything on the branchMerge commit or fast-forwardYou want the whole branch, divergence visible
git rebase <base>All branch commits, replayedLinear, rewritten SHAsYou want the branch as a clean linear run
git revert <sha>Inverse of a commitAdds an undo commitA landed commit must be undone on shared history

The one-line rule: cherry-pick moves a selection; merge and rebase move everything. Reaching for cherry-pick to "sync" with a branch is a sign you actually want a merge. One habit to skip: cherry-picking the same commit into several branches long-term — every future fix on the source branch needs another pick, and eventually the branches drift. Backports to release branches are a normal pattern; a permanent parallel universe is not.

THE WORKFLOW, CONDENSED

git log <source-branch> --oneline -5   # find the SHA(s)
git switch <target-branch>             # land in the right place
git cherry-pick A^..B                  # range, list, or single SHA
# on conflict: resolve → git add → git cherry-pick --continue
git log -1 --stat                      # confirm what landed

Find, switch, pick, verify. The command has a reputation for danger it does not deserve — the diff either applies or it stops and tells you why. The only genuinely destructive mistake is picking into the wrong branch, and git log -1 before you push makes that one hard to miss.

■ honest stamp cherry-pick · copy-not-move · merge/rebase for whole branches. First published 2026-09-12, record refreshed 2026-10-10. Every command runs as printed on any recent git; the range semantics (A..B excludes A), the empty-pick behaviour and the -m parent numbering are git's documented behaviour, typed from picks that really landed.

end of the pick page · nothing fetched · everything local