Three-Way Merge
Combining two lines of work by comparing both against their common ancestor.
A three-way merge combines two divergent versions by comparing each against their common ancestor — the merge base. Knowing the ancestor is what lets the algorithm distinguish "this side changed it" from "that side changed it", and to combine non-overlapping changes automatically.
The merge base is why comparisons must be taken against the ancestor rather than against the current tip of the other branch. Diffing a branch against the current main attributes every change made on main since the branch was cut to the branch itself. The three-dot form of a diff selects the merge base and is almost always what is wanted.
Two things merges cannot do.
They cannot detect semantic incompatibility. Non-overlapping changes are combined without complaint even when they contradict each other; see Semantic Conflict. Conflict absence is not agreement.
They cannot resolve genuine overlap, which is a Merge Conflict and requires a human decision.
There is also a duplication hazard: two branches that each added the same content in the same place can merge with no conflict markers and produce it twice, which a compiler catches and a reader might not.
See also5
Hand-picked in the note itself — the neighbours worth reading next.
Merge Conflict
Overlapping changes that a merge cannot combine automatically, requiring a decision.
Version Control & Delivery8 connections
Rebase
Replaying a branch's commits onto a new base, producing new commits with the same changes.
Version Control & Delivery10 connections
Semantic Conflict
Two changes that merge cleanly and are incompatible in meaning.
Version Control & Delivery12 connections
Version Control
A system recording the history of a project's files, enabling branching, merging, and recovery.
Version Control & Delivery13 connections
Merge Train
Validating changes against the state they will actually merge into, in order, rather than in isolation.
Version Control & Delivery9 connections
Related4
Nearby in the graph rather than deliberately chosen. Looser, sometimes surprising.
Linked from10
Notes elsewhere in the wiki that reach for this one.
- Branching ModelVersion Control & Delivery
The convention governing what branches exist, what they mean, and how work reaches production.
- CommitVersion Control & Delivery
A recorded snapshot of a project with a message explaining it.
- Continuous IntegrationVersion Control & Delivery
Automatically building and testing every change, so integration problems surface immediately.
- Merge ConflictVersion Control & Delivery
Overlapping changes that a merge cannot combine automatically, requiring a decision.
- Merge TrainVersion Control & Delivery
Validating changes against the state they will actually merge into, in order, rather than in isolation.
- RebaseVersion Control & Delivery
Replaying a branch's commits onto a new base, producing new commits with the same changes.
- Semantic ConflictVersion Control & Delivery
Two changes that merge cleanly and are incompatible in meaning.
- Stacked Pull RequestsVersion Control & Delivery
A chain of dependent changes, each reviewed separately and merged in order.
- Trunk-Based DevelopmentVersion Control & Delivery
Everyone integrating into one shared branch continuously, with short-lived feature branches.
- Version ControlVersion Control & Delivery
A system recording the history of a project's files, enabling branching, merging, and recovery.