Git Cherry-Pick Conflict, How to Abort or Finish Cleanly

A cherry-pick conflict works fundamentally like any other Git merge conflict — the difference worth understanding is specifically how to correctly finish or cleanly back out of a cherry-pick in progress, since it leaves the repository in a distinct intermediate state until you explicitly continue or abort it.

The Problem

Cherry-picking a specific commit onto your current branch fails partway through:

git cherry-pick a1b2c3d
Auto-merging src/utils.js
CONFLICT (content): Merge conflict in src/utils.js
error: could not apply a1b2c3d... Fix rate limit calculation

Your working directory now shows conflict markers, and it's not immediately clear whether the safest path forward is resolving and continuing, or backing out entirely.

Why It Happens

A cherry-pick conflict occurs for the same fundamental reason any merge conflict does — the commit you're applying changes lines that your current branch has also changed since diverging from wherever that commit originally came from, and Git can't automatically determine which version should win. What makes cherry-picking specifically worth understanding separately is that it leaves the repository in a distinct "cherry-pick in progress" state, tracked internally, until you explicitly resolve it one way or the other.

The Fix

To resolve the conflict and complete the cherry-pick, open the conflicted file, look for the conflict markers, and edit to the correct final state:

<<<<<<< HEAD
your current branch's version
=======
the cherry-picked commit's version
>>>>>>> a1b2c3d... Fix rate limit calculation

After resolving and removing the markers, stage the resolved file and continue the cherry-pick explicitly — a cherry-pick in progress doesn't complete automatically just from staging the fix, it needs an explicit continue command:

git add src/utils.js
git cherry-pick --continue

If, after seeing the conflict, you decide the cherry-pick isn't worth resolving right now (or you picked the wrong commit entirely), abort it cleanly to return your branch to exactly the state it was in before the cherry-pick began:

git cherry-pick --abort

This is the safe, clean way to back out — it undoes any partial changes the cherry-pick attempt introduced and returns you to a normal, conflict-free working directory, as if the cherry-pick had never been attempted at all.

If you're cherry-picking multiple commits at once and hit a conflict partway through the sequence, both --continue and --abort behave sensibly in this context too — --continue resumes with the remaining commits in the sequence after you resolve the current conflict, while --abort cancels the entire remaining sequence, not just the currently conflicted commit:

git cherry-pick a1b2c3d e4f5g6h i7j8k9l
# if a conflict occurs partway through:
git cherry-pick --continue  # resolves current, proceeds to next in sequence
# or
git cherry-pick --abort     # cancels the entire remaining sequence

If you want to skip just the currently conflicted commit specifically (without aborting the whole sequence, and without resolving this particular one), use --skip instead:

git cherry-pick --skip

Still Not Working?

If you're unsure whether a cherry-pick is currently in progress at all (for example, after stepping away and coming back to a repository in an unclear state), check directly rather than guessing:

git status

If a cherry-pick is genuinely in progress, git status explicitly reports this at the top of its output, along with the specific next-step commands (continue or abort) — trusting this output directly is more reliable than trying to infer the repository's state from file contents alone, especially after any amount of time has passed since the conflict first occurred.

It's also worth checking whether the conflict recurs identically every time you attempt the same cherry-pick, which can indicate the target branch and source commit have diverged so significantly that a clean cherry-pick genuinely isn't practical without substantial manual reconciliation. In that case, rather than repeatedly attempting and resolving the same conflict, consider whether manually applying the conceptual change (writing new code that achieves the same intent, rather than trying to force Git to merge the literal diff) might be faster and less error-prone than continuing to fight an increasingly complex conflict resolution.

Finally, if the cherry-pick is one of several being applied as part of a larger backport or hotfix process across multiple branches, keep a written record of which commits have already been successfully applied to which branches as you go — cherry-picking the same commit twice onto the same branch (by mistake, from working across multiple terminal sessions or team members) can itself become a source of confusing, hard-to-diagnose conflicts later, distinct from the original conflict you're currently resolving.