Resolving criss-cross merges

A criss-cross merge happens when two branches merge each other: release merges main to pick up a fix, and around the same time main merges release to pick up a patch. Each branch now contains a merge whose parents include the other’s commits, and when they are merged again there is no single best common ancestor — there are two, each equally close. Git handles this by merging the two bases together first, creating a virtual ancestor, and then using that as the base. Usually the result is fine. Sometimes the virtual ancestor itself contains conflict markers, and the conflicts you see make no sense. This page explains what is happening and how to resolve and prevent it, within 3-way merge fundamentals.

When to use this approach

  • git merge-base --all prints more than one commit for the branches you are merging.
  • Conflict markers contain nested markers, or the base section contains text neither side ever had.
  • Two long-lived branches — main and a release branch, or two integration branches — merge in both directions.
  • You are designing a branching model and want to avoid the pattern, as covered in GitFlow vs GitHub Flow comparison.

Step 1 — Confirm there is more than one base

The defining symptom is several merge bases.

git merge-base --all main release/2.4
# a1b2c3d...
# e4f5a6b...
git log --oneline --graph --boundary main...release/2.4 | head -30
How a criss-cross formsMain and the release branch both start from A. Main commits M1 and the release branch commits R1. Then main merges R1 and the release branch merges M1 at about the same time. Both later tips now share M1 and R1 as equally good common ancestors.two merges in opposite directionsmainAM1merge R1M2releaseAR1merge M1R2basesM1 · R1neither M1 nor R1 is closer to both tips, so Git must use both How a criss-cross formsMain and the release branch both start from A. Main commits M1 and the release branch commits R1. Then main merges R1 and the release branch merges M1 at about the same time. Both later tips now share M1 and R1 as equally good common ancestors.two merges in opposite directionsmainAM1merge R1M2releaseAR1merge M1R2basesM1 · R1neither M1 nor R1 is closer to both tips, so Git must use both

Step 2 — See the virtual ancestor Git will use

The default ort strategy merges the bases recursively into a temporary commit and uses that as the base. You can reproduce it to understand the conflicts it causes.

# Merge the two bases yourself, exactly as Git would, without touching any branch
bases=$(git merge-base --all main release/2.4 | tr '\n' ' ')
set -- $bases
git merge-tree --write-tree "$1" "$2"
# The first line is the tree ID of the virtual ancestor; following lines list conflicts in it

If the bases merge cleanly, the virtual ancestor is a normal tree and the final merge behaves normally. If they conflict, the virtual ancestor contains conflict markers as ordinary text, and that text then appears in the base section of your final conflicts.

# Verification: inspect a file from the virtual ancestor
tree=$(git merge-tree --write-tree "$1" "$2" | head -1)
git show "$tree:config/app.yml" | grep -n '<<<<<<<' || echo "virtual base is clean for this file"

Step 3 — Read nested conflicts calmly

When the virtual ancestor itself had a conflict, your final conflict shows that inner conflict inside the base section, with longer markers to distinguish the levels.

<<<<<<< HEAD
max_connections = 200
||||||| merged common ancestors
<<<<<<<<< Temporary merge branch 1
max_connections = 120
=========
max_connections = 150
>>>>>>>>> Temporary merge branch 2
=======
max_connections = 150
>>>>>>> release/2.4
Two levels of conflict in one blockThe outer markers separate ours, the base and theirs as usual. Inside the base section, longer markers show that the two merge bases themselves disagreed. The inner conflict tells you the history was contested before either current change was made.outer conflict containing an inner oneours (HEAD)max_connections = 200base: Temporary merge branch 1120 — first merge basebase: Temporary merge branch 2150 — second merge basetheirs (release/2.4)max_connections = 150theirs matches one of the bases, so theirs effectively made no change here Two levels of conflict in one blockThe outer markers separate ours, the base and theirs as usual. Inside the base section, longer markers show that the two merge bases themselves disagreed. The inner conflict tells you the history was contested before either current change was made.outer conflict containing an inner oneours (HEAD)max_connections = 200base: Temporary merge branch 1120 — first merge basebase: Temporary merge branch 2150 — second merge basetheirs (release/2.4)max_connections = 150theirs matches one of the bases, so theirs effectively made no change here

Read it the usual way, treating the inner conflict as “the base was either 120 or 150”. Theirs is 150, identical to one base, so theirs probably did not change this line. Ours changed it to 200. The likely resolution is 200 — but because the history was contested, confirm with whoever made the release-branch merge.

Step 4 — Resolve, then record why

Resolve file by file. For each conflict, compare ours and theirs against both candidate bases; a side that matches either base made no change. Record anything non-obvious in the merge commit message, because the next person to look at this history will face the same puzzle.

git merge release/2.4
# resolve each file
git add config/app.yml
git commit -e     # add a note: "criss-cross: bases a1b2c3d and e4f5a6b disagreed on max_connections"

If you want to see how a resolution differs from what Git would have produced on its own, git show --remerge-diff on the merge commit shows exactly that; see reviewing conflict resolutions with remerge-diff.

Step 5 — Prevent criss-crosses with one-way flow

Criss-crosses come from merges in both directions between long-lived branches. A one-way rule removes them: fixes flow in one direction only, typically from the oldest supported branch forward, or from main to release branches by cherry-pick.

Two-way merging against one-way flowWhen main and a release branch merge each other, criss-cross histories and multiple merge bases follow. When changes flow only one way — release into main by merge, or main into release by cherry-pick — every merge has a single base and conflicts stay readable.Merge both waysOne-way flowmerge basesoften severalonenested conflictspossibleneverfix propagationeither directionforward merge or cherry-pickpick a direction for each pair of long-lived branches and never reverse it Two-way merging against one-way flowWhen main and a release branch merge each other, criss-cross histories and multiple merge bases follow. When changes flow only one way — release into main by merge, or main into release by cherry-pick — every merge has a single base and conflicts stay readable.Merge both waysOne-way flowmerge basesoften severalonenested conflictspossibleneverfix propagationeither directionforward merge or cherry-pickpick a direction for each pair of long-lived branches and never reverse it 
# A cheap guard: fail if a branch has more than one merge base with main
n=$(git merge-base --all origin/main HEAD | wc -l)
[ "$n" -le 1 ] || { echo "criss-cross history with main ($n bases) — check merge direction"; exit 1; }

The forward-only patterns are covered in cherry-picking hotfixes across release branches.

Validation checklist

Frequently Asked Questions

Is a criss-cross merge a problem if it merges cleanly?

Not by itself. Git’s recursive handling of multiple bases works well most of the time. It becomes a problem when the bases conflict with each other, which is more likely the longer both branches live and the more they diverge.

Would the resolve strategy avoid this?

The resolve strategy picks one of the bases instead of merging them. That avoids nested markers but can produce worse results, because it ignores changes captured only in the other base. The default is the better choice.

Can rebasing remove a criss-cross?

Rebasing one branch onto the other rewrites its history so it no longer contains the cross-merge, leaving a single base. That is only appropriate for branches nobody else has based work on; for shared long-lived branches, prevention is the practical fix.