Integration and conflicts

Git's merge machinery addresses textual merging and makes no claim about the other problem, whether the result is behaviourally correct. The default strategy for two heads is ort, a 3-way merge that builds a merged tree of multiple common ancestors where they exist and that detects renames.¹ A conflicted path is recorded in the index in three stages, the common ancestor, HEAD and MERGE_HEAD, and the working tree gets the marker lines.¹ The merge.conflictStyle setting can add a base section with diff3, or trim lines matching on both sides from the edges of the region with zdiff3.¹ All of that describes the resolution of textual conflicts. The documentation makes no claim about whether a clean merge is behaviourally correct.¹

One case parallel integration has to account for is the one git does not name: two branches that merge with no marker anywhere and are still behaviourally incompatible. This volume calls that a semantic conflict. No primary source was found defining the term, so treat it as this volume's framing rather than a git concept, and treat a clean merge as the point where verification starts rather than the point where it ends.

Mechanically, parallel work integrates more calmly than it sounds. By default, git worktree add refuses to check out a branch already checked out elsewhere, unless forced, and that is what normally keeps parallel agents on distinct branches.² Because all worktrees share one object database and one set of refs, a commit made in one worktree is visible to every other immediately, with no push or fetch.³ Claude Code will not let a worktree session write into the main checkout at all, so integration has to happen as an explicit git operation.⁴ At the far end, a GitHub merge queue builds temporary branches combining the base branch with the pull requests ahead in the queue, merges in first-in-first-out order with required checks satisfied, and removes a pull request whose checks fail before rebuilding without it.⁵ Keep uncommitted work out of the way while integrating: git stops when local changes overlap files the merge would update, and the documentation warns that git merge --abort can fail to reconstruct uncommitted changes that existed when the merge began.¹

When this does not hold. None of this says how bad it gets at scale. No measurement was found of conflict rate or conflict severity as a function of the number of parallel agents or branches, from any vendor or study, and none of whether an agent resolves a conflict more or less reliably than a person does. Ordering is documented only as merge-queue first-in-first-out batching. A heuristic such as smallest diff first has no source behind it.