Merge Strategies

Merge Strategies and the ORT Algorithm

A true merge is a three-way merge: Git 1,932 compares each tip with the merge base, their best common ancestor. A hunk changed on one side is taken from that side, and one changed differently on both is a conflict. Plumbing replays the merge you just made:

Finding the merge base and merging in memoryShell
git merge-base HEAD^1 HEAD^2
git merge-tree --write-tree HEAD^1 HEAD^2
git rev-parse 'HEAD^{tree}'
Output
7267a50d6562aa54553178ead829875ad624e1d3
9aa46d4a76ea966d239b495a0ba0e3729b6ed76e
9aa46d4a76ea966d239b495a0ba0e3729b6ed76e

The base of the merge's two parents is the search commit. git merge-tree --write-tree merges in memory, touching neither index nor working tree, and prints the tree the merge commit recorded; hosting services run it to test whether a pull request merges cleanly.

The engine is ORT, "Ostensibly Recursive's Twin", Elijah Newren's rewrite of recursive, and the default since Git 2.34 (November 2021); since Git 2.50 -s recursive is only a synonym. It is fast and rename-aware: a file renamed on one branch and edited on the other merges cleanly. 7 lists the alternatives.

Merge strategies and ORT options in Git 2.55
Strategy or option What it does Typical use
-s ort (default) Three-way merge of two heads, rename-aware Almost every merge
-s octopus Merges three or more heads; stops at any conflict Bundling topic branches
-s ours Keeps the current tree, records the other side as merged Retiring a branch
-X ours, -X theirs Settles conflicting hunks for one side Generated files