What cherry-pick does

git cherry-pick takes a commit from one branch and applies it as a new commit on the current branch. The original commit is unchanged; the new commit has the same content but a fresh SHA, parent, and committer date.

The basic operation

git checkout release/1.4
git cherry-pick <sha>

This is how hotfixes commonly travel: develop a fix on main, cherry-pick onto release/x.y branches.

Cherry-picking ranges

git cherry-pick <sha1> <sha2> <sha3>
git cherry-pick <older>..<newer>        # range, exclusive of older
git cherry-pick <older>^..<newer>       # range, inclusive of older

Cherry-picking with conflicts

git cherry-pick <sha>
# CONFLICT detected
# ...resolve...
git add <file>
git cherry-pick --continue
# or to abort
git cherry-pick --abort

Recording origin in the message

git cherry-pick -x <sha>

-x appends "(cherry picked from commit <sha>)" to the message. Recommended for back-ports - it documents the lineage.

Cherry-picking merges

git cherry-pick -m 1 <merge-sha>

-m 1 picks the diff against parent 1 - the mainline side. Cherry-picking merges is rarely the right move; usually you want to pick the feature commits individually instead.

Cherry-pick versus merge

• Merge - integrates a whole branch; preserves the link.
• Cherry-pick - copies a specific commit; no link.

Cherry-pick when you want one specific change without dragging in everything else on the branch. Merge when you want all of the branch's content.

The duplicate-commit problem

If you cherry-pick a commit that already exists on a downstream branch, you get a conflict or a no-op. Worse, when you eventually merge the branches, Git may show duplicate-looking commits. Tools that detect equivalents:

git cherry main feature        # show which feature commits are in main
git rebase --skip               # if rebase finds an already-applied commit

Empty cherry-picks

If the change is already present, cherry-pick may produce an empty commit:

git cherry-pick --allow-empty <sha>        # keep it
git cherry-pick --skip                       # discard and move on

Workflows where cherry-pick shines

• Hotfix from main back to a release branch.
• Promoting a fix from a feature branch to main while leaving the rest of the feature in progress.
• Reapplying a commit lost during a rebase.
• Selectively forwarding fixes between maintenance lines.

Workflows where cherry-pick hurts

• Trying to merge two branches by picking every commit one at a time - use merge or rebase instead.
• Cherry-picking from a long-lived branch repeatedly - you accumulate divergent commits that confuse git cherry.

Best practices

• Always use -x for back-ports. Lineage matters.
• Reference the source PR or ticket in the cherry-picked commit message.
• Run tests on the destination branch - the same code on a different base can behave differently.

Cherry-pick is a sharp tool. Reach for it deliberately, document the lineage, and the maintenance overhead stays low.