Cherry-pick multiple Git commits

Run git cherry-pick A B C to apply specific commits in the order listed. For a contiguous linear sequence, use a revision range such as A^..B to include A through B. Replace these symbolic examples with real commit IDs or refs.

Select a range carefully

# Inspect the three first-parent steps before the tip.
git log --reverse --oneline feature-x~3..feature-x
git cherry-pick feature-x~3..feature-x

On a linear branch this selects the last three commits. In a merge history, the range can include additional commits from merged branches. Ranges describe reachability sets, not a fixed slice of visually adjacent log lines.

A..B excludes commits reachable from A; A^..B excludes those reachable from its first parent and therefore includes A when it lies in the selected ancestry. A root commit has no A^. Inspect the selection first, especially if it contains merges. Git performs a revision walk when given a range; do not assume an arbitrary range has the same ordering semantics as an explicit list.

Apply separate commits

git cherry-pick a1b2c3d b2c3d4e c3d4e5f

Start with a clean checkout and order changes so dependencies are available when needed. Git generally creates a new commit for each successful pick on the current branch; it does not move the source branch.

Continue, skip, or abort

# Resolve the current conflict, then stage the result.
git add -- path/to/resolved-file
git cherry-pick --continue
# Alternatives:
# git cherry-pick --skip
# git cherry-pick --abort

--skip omits the current pick. --abort abandons the sequence and restores its starting state. Save resolution work separately if you may want it later.

Useful options

For a conflicted pick, inspect the eventual message if your process requires an origin line; -x is documented to add it automatically only for conflict-free picks. A merge commit requires a mainline parent, for example -m 1; that applies its change relative to that parent, not its whole ancestry.

FAQ

What happens if I pick a change already present? The result may be empty and Git can stop for a decision. It does not invariably duplicate the content. Version-specific empty-commit options can change that behavior.

Should I merge instead? Merge integrates ancestry and branch changes; cherry-pick is useful for selected backports. Later merges are not guaranteed to conflict merely because a change was cherry-picked, though different surrounding edits can still conflict.

See git-cherry-pick and revision ranges.