Three-Way Merge

How Three-Way Merge Works

Three-way merge is built around a base revision plus two changed versions, which lets version control systems distinguish shared history from new edits. That comparison model is what makes merges more accurate than a simple line-by-line overwrite when the same file has diverged in parallel.

In practice, the merge engine evaluates what changed in each branch relative to the common ancestor, then attempts to combine non-overlapping edits automatically. When both sides touched the same lines or nearby context, the tool flags a conflict instead of guessing, because preserving intent matters more than silently choosing the wrong edit.

This model is especially useful in collaborative software development, where many contributors may change the same file over time. It also supports cleaner auditability because the merged result can be traced back to the two inputs and their shared base, which helps explain why a specific hunk was accepted, rejected or marked for review.

Why Three-Way Merge Reduces Conflict Risk

The common-base approach reduces ambiguity because the merge tool is not comparing two entire file snapshots in isolation. It can tell whether a line was changed by one side, both sides, or neither, which lowers the chance of accidentally discarding work when edits are adjacent but not identical.

This is why three-way merge is the standard approach in distributed version control. A simpler two-way comparison can misread one branch’s edits as an overwrite, while three-way merge uses history to separate independent changes from true collisions.

Merge conflicts are not failures of the algorithm so much as a signal that human judgment is needed. The danger is not the conflict prompt itself, but the temptation to resolve it mechanically without understanding which edit reflects the intended behaviour, configuration or documentation.

Where Three-Way Merge Fits in Version-Control Workflows

Three-way merge sits at the centre of branch-based collaboration. It is the mechanism that lets teams work in parallel, then reconcile work at integration time rather than forcing everyone to edit the same trunk line by line.

Git’s use of base, ours and theirs versions is more than naming convention, it is an operational model for deciding what belongs in the final tree. “Ours” and “theirs” are only meaningful relative to the merge base, so the same labels can be understood correctly only in the context of that shared ancestor.

Because the result is produced from history rather than a blind overlay, the method also supports safer rebasing, pull requests and release integration. The quality of the merge, however, still depends on the quality of the base revision and on whether branches have drifted too far apart before integration.

What Practitioners Should Watch For During Merge Resolution

Three-way merge works best when the file is structurally stable and the changes are logically separated. It becomes harder to review when a file is large, heavily reformatted or touched by many authors, because the conflict markers may be technically correct but still difficult to resolve safely.

Conflicts deserve extra attention when the file contains security-sensitive logic, access rules, deployment configuration or other material where a small edit can change behaviour. In those cases, the merge result should be reviewed for unintended deletions, duplicated settings and subtle precedence changes, not just for syntax correctness.

After a merge, teams should treat the result as a new decision point, not merely a completed technical step. The merged file should be checked for consistency, and the surrounding tests or validation should confirm that both branches’ intended changes survived the integration process.

Related resources from NHI Mgmt Group

• How does the TCP three-way handshake work?
• What does the TCP three-way handshake look like in practice?
• Three-Way Matching
• Three-Way Match