When a cherry-pick conflicts, stop and read both sides. The old branch may have different code around the bug. Resolve by hand, keep the change minimal, add a test that fails without it, and have a second person review it, because a conflicted backport is a new patch.
What a conflict tells you
Git documents that when a cherry-pick cannot apply cleanly, the index records the conflicting paths and the files get the usual conflict markers. That is Git saying the surrounding code differs between the two branches. For a security fix, that difference is information: the vulnerable code on the old line may not look like the code on main.
Steps
- Run the cherry-pick on a branch created from the old release tag, not on the release branch itself.
- Open each conflicted file and compare what the fix intended to change with what the old code does.
- Check whether the old branch even contains the vulnerable code path. Sometimes it does not, and the right action is a note, not a patch.
- Make the smallest edit that has the same effect as the original fix.
- Port the test from the original commit. If the test helpers differ, rewrite it so it still fails before the fix.
- Run the full suite for that branch.
- Ask for review from someone who did not do the resolution.
git checkout -b backport/2.3.x-fix v2.3.4
git cherry-pick -x abc1234
# resolve conflicts, then
git add -A
git cherry-pick --continue
Choose between three outcomes
| Situation | Action |
|---|---|
| Conflict is only context lines | Resolve and proceed |
| Old code is structured differently | Rewrite the fix for that branch |
| Fix depends on many newer commits | Consider ending support for that line |
The third row is a business decision. Pulling a dozen prerequisite commits into an old branch turns a patch release into a feature release, with all the risk that implies. Say so to customers and give them a supported upgrade path.
Keep the paper trail
The cherry-pick command has an option that appends a line of the form cherry picked from commit followed by the original hash to the message. Use it. When someone audits the branch later, that line links the backport to the reviewed original, and your scanner or reviewer can compare them. The detail of why this matters is covered in a separate post on recording where a backported patch came from.
Mistakes to avoid
- Resolving conflicts by taking the incoming side blindly.
- Skipping the old branch's tests because main is green.
- Shipping the backport without bumping the patch version.
- Forgetting to note in the changelog that the fix covers this line.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings are tracked to closure across the components you run.
Safeguard can show which components in each supported release carry a vulnerability, using SBOM and dependency scanning, so you know which branches actually need the backport. Try a free scan at gold.safeguard.sh/scan.
Quick check
Is a conflict a sign the fix does not apply?
Not necessarily. It means the code around the fix differs. Check whether the vulnerable code exists on that branch before deciding.
Does a backport need its own review?
Yes. A conflicted backport is a different patch from the original, so it needs fresh review and its own test run.
Sources
Last reviewed: 19 October 2026.
