How to Cherry-Pick Merge Commit in Git

git cherry-pick applies the changes introduced by selected commit(s) to the current branch and records the result as a new commit. It does not move the original commit, copy its ancestry, or bring over every commit in a branch. This is useful when a fix or feature commit belongs on another branch but merging or rebasing the entire branch would include unrelated work.

What git cherry-pick does

For an ordinary commit, Git compares that commit with its parent and applies the resulting change to the current HEAD. The new commit has a different identity and parent: the original remains in its branch, while the new commit joins the branch you checked out. For example, after switching to the branch that should receive a selected fix, git cherry-pick <commit> applies that one commit’s change. A range can select multiple commits, but cherry-picking a range still creates new commits; it does not merge the source branch’s history as a whole.

A merge commit needs extra care because it records the combined result of two or more parents. Git cannot infer which parent’s changes should be treated as the baseline for a cherry-pick. The -m option supplies that choice.

How the mainline parent determines the changes applied

Consider a merge commit P with first parent O and second parent T. The parent order is stored in the commit itself. In this simplified graph, O is the tip of the branch that received the merge, while T is the other side: ...—N—O—P is the main branch, and N—T—P is the topic branch. Both lines meet at merge commit P.

For a merge commit, git show --no-patch --pretty=raw P displays its parent object IDs in order. The first listed parent is mainline 1, and the second is mainline 2. These numbers describe the recorded order, not branch names; inspect the IDs and surrounding history before choosing.

Conceptually, -m 1 P applies the net difference from P’s first parent to P. -m 2 P applies the net difference from its second parent to P. In the graph above, the first choice represents the changes that arrived on main through the merge relative to O; the second represents the merge result relative to T, which can include changes from the other side. Neither choice means “copy all commits along this path.” The target branch’s existing files also affect whether the selected change applies cleanly.

Cherry-pick a merge commit with -m

First inspect P’s parents with git show --no-patch --pretty=raw P, then decide which parent is the baseline appropriate to your goal. Run this self-contained shell example to create a local merge commit and apply its first-parent change on a release branch:

set -eu
repo=$(mktemp -d)
trap 'rm -rf "$repo"' EXIT
cd "$repo"
git init -q -b main
git config user.name Example
git config user.email example@example.test
printf 'base\n' > base.txt
git add base.txt
git commit -qm base
git switch -q -c topic
printf 'topic change\n' > topic.txt
git add topic.txt
git commit -qm topic
git switch -q main
printf 'main change\n' > main.txt
git add main.txt
git commit -qm main
git merge --no-ff -q topic -m merge
merge_commit=$(git rev-parse HEAD)
git switch -q -c release "${merge_commit}^1"
git cherry-pick -m 1 "$merge_commit" >/dev/null
printf 'Cherry-pick completed on release.\n'

Cherry-pick completed on release.

The command supplies both required pieces: -m 1 selects the first recorded parent, and merge_commit identifies the merge commit. Use -m 2 only when the second parent’s perspective is the intended change. In your own repository, replace the example branch and commit ID with the destination and merge commit you inspected.

Afterward, inspect git show --stat --oneline HEAD and git diff HEAD^ HEAD to review the new commit and its patch. Also check git status --short to confirm whether the working tree has other changes. These checks help catch a valid but unintended patch before you push or build on it.

Handle conflicts and verify the result

If changes in the destination branch overlap with the selected patch, Git stops and marks conflicted paths. Review each file, edit it to the intended combined result, and stage the resolutions with git add <path>. Then run git cherry-pick --continue to finish. Do not continue until the staged content is correct: conflict resolution can produce a patch different from the one in the merge commit.

If the attempted result is not wanted, use git cherry-pick --abort while the operation is in progress. This returns the branch and working tree to their pre-operation state for that cherry-pick. If a cherry-pick has already completed, inspect the branch and decide how to undo the new commit using your team’s normal history policy; do not assume abort can undo a completed operation. Check status and review the resulting commit before sharing it.

Risks and alternatives

Choosing the wrong mainline can apply a surprising or overly broad net change. Cherry-picking also creates new commit identities, so the same logical change may later appear twice if the original branch is merged. It does not erase the source commit or its history, but the two copies can complicate later integration and review. Inspect the parent order, compare the resulting patch with the intended change, and confirm the destination branch before proceeding.

Use a normal merge when the goal is to integrate a branch and preserve its relationship to the destination. Rebasing is appropriate when the goal is to replay a branch’s commits onto a new base and your collaboration policy allows rewriting that branch. Cherry-pick fits a deliberately selected change; it is not a substitute for integrating a whole line of development.