Three-way merge is a file merge method that combines two changed versions by comparing each one with a common base revision. Git uses the base, ours and theirs versions to align edits, reduce conflicts and record a merged result when changes overlap or diverge.
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.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, OWASP SAMM and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | Three-way merge protects source code integrity during collaborative change. |
| Recommendation — Use secure code review and change-control safeguards to verify merged code before release. | ||
| OWASP SAMM | Deployment — Deployment | Merge resolution is part of secure software delivery and release integrity. |
| Recommendation — Build merge review checks into delivery gates before code reaches production. | ||
| SLSA | Supply Chain Levels for Software Artifacts | Three-way merge supports traceable source history in software provenance workflows. |
| Recommendation — Preserve source history and verify integration steps that affect build provenance. | ||