What cherry-pick does in Git

Cherry-pick applies the change introduced by a selected commit to your current branch. It is useful when you need a particular fix without integrating all the history reachable from the source branch.

Apply a release backport

Start with a clean working tree and inspect the chosen commit:

git switch release-1.2
git show a1b2c3d
git cherry-pick -x a1b2c3d

The selected change might fix a bug on main while other mainline features are not ready for release. Inspect its dependencies and run the release branch's tests; applying without conflicts does not prove the backport works.

Other uses include adopting a small utility from an experimental branch or moving work committed to the wrong branch. Removing the unwanted effect from a shared source branch is a separate, usually revert-based decision. Do not reset shared history casually.

Understand what gets copied

Cherry-pick applies a commit's change relative to its parent, not a snapshot of all source files. A normal pick creates a new commit and leaves the original branch ref unchanged. With --ff, Git can instead fast-forward when the current tip matches the picked commit's parent.

To select a linear sequence, git cherry-pick 'A^..B' includes A through B when A has a parent. Inspect the range first: merges can include additional reachable history, and the root commit has no parent. Explicit IDs are often clearer for a small backport.

Resolve conflicts

# Resolve the conflicted content, then stage it.
git add -- src/app.js
git cherry-pick --continue
# To abandon the active operation instead:
git cherry-pick --abort

A merge commit needs a mainline-parent choice with -m; selecting its individual component changes can be easier to review. If the change is already present and the pick becomes empty, inspect why before deciding to skip or retain an empty commit.

Preserve useful provenance

-e opens the commit message for editing. -x adds source-commit information in supported cases; inspect it after conflict resolution and include the original ID explicitly when the release process requires that record.

The same logical change may then exist under different IDs. A later merge uses ancestry and merge mechanics, not a general “skip duplicate commits” rule. It may combine identical changes cleanly, but conflicts are still possible and both histories remain visible.

Compare it with rebase

Rebase replays a selected sequence onto a new base and updates the rebased branch. Cherry-pick applies selected changes to the current branch without moving the source ref. Original commits can remain reachable through other refs after either operation; rebase does not inherently erase every reference to the old history.

See git-cherry-pick and git-rebase.