In Git, what does merging with -X ours do, and how is that different from -s ours?

## Two flags, one word, different scopes The similar spelling hides a large difference in blast radius: - `git merge -X ours <branch>` — full three-way merge; `ours` decides only **conflicting hunks**. - `git merge -s ours <branch>` — no content merge at all; the result's tree **is** the current branch's tree. ## What -X ours actually does The normal merge runs. Git finds the merge base, diffs both sides against it, and applies both sets of changes. Where the two sides changed different regions, both changes land — including everything the other branch did to files you never touched. Only when a hunk conflicts, meaning both sides changed the same region relative to the base, does the option take effect: instead of leaving conflict markers and stopping, Git takes our version of that hunk and continues. So `-X ours` is best described as "auto-resolve contested regions in our favour". Some consequences follow directly: - The merge completes without stopping, so nobody reviews the contested regions unless they read the resulting diff. - The other side's edit to each contested region is **discarded**, permanently as far as this branch's content is concerned. It remains reachable in the other branch's commits, but it is not in the merge result. - The merge commit itself records no marker that automatic resolution happened. Reading `git log` later gives no hint. - Whole-file conflicts (for example modify/delete) are decided by the same preference. `-X theirs` is the exact mirror: contested regions resolve to the incoming side. ## What -s ours actually does Here no merging occurs. Git creates a merge commit with the usual parents — the current branch first, the merged branch second — but the commit's tree is copied from the current branch. Nothing from the other branch is in the result, whether it conflicted or not. A file that only the other branch created simply does not appear. The value is in the **ancestry**, not the content. The merge records "this branch is now contained in mine", which advances the merge base for future merges and makes `git branch --merged` list it. It is the tool for deliberately declaring a branch superseded. It also accepts more than two heads, resolving any number of branches to the current tree. ## The comparison in one table of outcomes Consider merging `feature` into `main`, where `feature` changed `a.txt` (untouched by main) and both changed the same block of `b.txt`: - **plain merge**: `a.txt` takes feature's change; `b.txt` conflicts and stops for resolution. - **`-X ours`**: `a.txt` takes feature's change; `b.txt` silently keeps main's version. - **`-X theirs`**: `a.txt` takes feature's change; `b.txt` silently takes feature's version. - **`-s ours`**: `a.txt` keeps main's version — feature's change is gone; `b.txt` keeps main's version. The tree equals main's tree exactly. ## There is no -s theirs Git provides no `theirs` strategy. The asymmetry surprises people who assume every option has a mirror. If you genuinely want the other branch's tree while keeping merge ancestry, you have to construct that result yourself rather than reach for a flag — and you should ask first whether replacing the branch content is really what you want. ## When each is defensible `-X ours` / `-X theirs` are legitimate for content where one side is authoritative by construction: regenerated files, vendored artefacts, machine-produced output. They are a poor default for hand-written code, because the whole point of a conflict is that two humans made incompatible decisions and one of them needs to read both. `-s ours` is legitimate when you consciously want to record that a branch is closed out without importing its content — abandoning a line of work while stopping it from resurfacing in every future merge. ## The reviewing habit that goes with them Because both flags suppress the signal Git would otherwise raise, pair them with an explicit check. Before merging, `git log --oneline main..feature` shows what you are about to make decisions about. Afterwards, comparing the merge result against the second parent shows exactly what was not taken. Saying this out loud in an interview is what separates "I know the flag" from "I would use it safely".