Cherry-pick conflicts — when the replay does not apply cleanly

A cherry-pick conflicts when the three-way merge machinery cannot produce a clean text. The state of the file at the merge base (the parent of the source commit) and the state at the current branch tip disagree on a region that the source commit also touched, and Git refuses to guess which side to keep. The mechanics, the conflict markers, and the resolution process are identical to what you have already seen in git merge and git rebase; the only difference is which command you resume.

When a cherry-pick will conflict

The merge base of a cherry-pick is the parent of the source commit, not the common ancestor of two branch tips. This makes cherry-pick conflicts more common than merge conflicts in one specific case: when the current branch has moved on from the parent of the source commit in a way that touches the same lines.

flowchart TB
    subgraph base["merge base = parent of X"]
        F0["file v0"]
    end
    F0 --> F1["file v1 - on current branch"]
    F0 --> F2["file v2 - source commit X"]
    F1 -. "both sides modified" .-> C["conflict"]
    F2 -.-> C

The textual conflict appears even when the semantic change is compatible — for example, when the current branch renamed a variable the source commit also renamed, or formatted a block the source commit reformatted. The three-way merge algorithm compares text, not intent.

The conflict state

When a cherry-pick conflicts, Git stops with CHERRY-PICK HEAD added to .git/HEAD, leaves the conflict markers in the affected files, and updates the index with the unmerged entries. From this point, you have four ways forward:

COMMIT=abc1234
git cherry-pick $COMMIT
# CONFLICT (content): Merge conflict in deploy.yaml
git status
# both modified:   deploy.yaml

You can now edit the file, git add the resolution, and then either commit (which ends the cherry-pick) or run git cherry-pick --continue, which creates the cherry-pick commit using your staged resolution.

—continue, —abort, —quit

These three flags control the lifecycle of an in-progress cherry- pick that hit a conflict:

git cherry-pick --continue
# stage resolution, then create the cherry-pick commit with the
# original message (or the edited message if you used -e)

git cherry-pick --abort
# revert working tree and index to the state before the cherry-pick;
# the in-progress CHERRY-PICK HEAD is cleared

git cherry-pick --quit
# forget the in-progress cherry-pick but leave your working tree and
# index as they are; useful when you want to resolve manually,
# commit by hand, and never let Git auto-commit for you

--abort is the right choice when you have decided the cherry-pick is wrong. --quit is the right choice when you want the changes but want full control over the resulting commit (message, author, splitting, squashing).

When —no-commit (-n) is the right tool

git cherry-pick -n <commit> (also written --no-commit) applies the changes to the working tree and stages them in the index, but does not create a commit. This is the right choice in three production cases:

1. You want to combine multiple cherry-picks into a single commit. Run several git cherry-pick -n commands in sequence; they accumulate in the index. When the batch is right, run git commit once.
2. You want to edit the message, author, or contents before committing. The staged changes are yours to modify with git add -p or by hand.
3. You are scripting a batch operation and want the script to control the commit step. A non-interactive CI pipeline often prefers -n so the resulting commit can carry metadata the pipeline generates (ticket numbers, build IDs).

git cherry-pick -n abc1234
git cherry-pick -n def5678
git status
# both modified:   deploy.yaml
git commit -m "backport: combined hotfix from abc1234 and def5678"

UnderTheHood: the cherry-pick state machine

Like git merge and git rebase, git cherry-pick writes a special marker to .git/HEAD (in this case CHERRY-PICK HEAD) while a cherry-pick is in progress. The marker is what tells Git that the next git commit (or git cherry-pick --continue) should finish this cherry-pick rather than start a new one. Removing the marker by hand (or with --abort) ends the cherry-pick. If you find yourself with a stuck CHERRY-PICK HEAD after deleting the branch you were picking onto, git cherry-pick --quit is the safe cleanup.

Production discipline

The production discipline for cherry-pick conflicts is the same as for any merge conflict, with two additions:

1. Resolve in the working branch, not by re-applying. Do not copy the file from another branch to “fix” the conflict; resolve it textually so the resulting tree is intentional.
2. Verify the resolution builds before --continue. A cherry-pick that compiles on the source branch may not compile on the target branch if APIs, schemas, or feature flags have changed. A CI run after --continue is the only authoritative check.

Cross-course references

• Git, CI/CD & GitOps — Part IX (Merging) — three-way merge machinery and conflict-marker conventions; cherry-pick conflicts are the same conflicts.
• Git, CI/CD & GitOps — Part XI (Rebasing) — --continue and --abort semantics in cherry-pick are inherited from rebase (they share the same sequencer machinery under the hood).
• Linux for Production Sysadmins — Part XX (Patching) — the contrast between patch (literal text application) and Git’s three-way merge is the cleanest way to internalise why a cherry-pick can succeed where a patch would fail and vice versa.

Quiz