When would you deliberately record a merge with git merge -s ours instead of taking the branch's changes?
answer
- Ancestry without content
- Think about future merge bases
- Used to retire a branch
- The log cannot show what was dropped
basics
~20 sUse it to declare a branch superseded: the merge records ancestry while keeping the current tree, so the branch stops appearing as unmerged and future merges only bring commits made after that point. The risk is silently discarding real work.
solid answer
~50 s`-s ours` produces a merge commit whose tree is exactly the current branch's tree, so nothing from the merged branch lands. Its value is purely in the ancestry: the branch tip becomes reachable, `git branch --merged` lists it, and the merge base advances so that a later merge only considers commits made after this point. That makes it the right tool for retiring an abandoned line of work, or for recording that a maintenance branch's content is intentionally superseded after a rewrite, without dragging obsolete changes forward. The danger is that it looks like a merge in the log while importing nothing: a reviewer skimming history cannot tell that content was dropped. So I would require an explicit commit message stating what was discarded and why, and check `git log --oneline <target>..<branch>` beforehand so the decision is made with the list in front of you.
code
console · 6 lines$ git log --oneline main..legacy-parser
3d21ba7 experimental tokenizer
$ git merge -s ours legacy-parser -m "Record legacy-parser as superseded; content intentionally not taken"
Merge made by the 'ours' strategy.
$ git branch --merged main
legacy-parsergo deeper
Know that -s ours records a merge without taking any of the other branch's files, and that it is not a way to resolve conflicts.
Explain the mechanism: the merge commit reuses the current tree, so only the ancestry link changes and the merge base advances.
Show the operational consequence — the branch reads as merged and its work will never be offered again — and the checks you run before and after.
Own it as a way of writing a decision into history: justify it in the commit message, port anything valuable first, and treat the excluded diff as a reviewable artefact.
## What the strategy does `git merge -s ours <branch>` creates a normal merge commit — current branch as first parent, the merged branch as second — but takes the tree from the current branch verbatim. No three-way merge runs. Files only the other branch created do not appear; changes only it made are absent. It accepts more than two heads, resolving any number of branches to the current tree. In other words, this strategy contributes **ancestry without content**. Everything worth knowing about when to use it follows from that. ## What the ancestry buys Git answers three questions from ancestry alone: - **Is this branch merged?** `git branch --merged` tests reachability, so after a `-s ours` merge the branch is reported as merged. - **What is left to merge?** `git log --oneline main..branch` becomes empty, then lists only commits made after the recording merge. - **What will a future merge consider?** The merge base moves to the `-s ours` commit, so subsequent merges from that branch diff only from there forward. That third point is the operational payoff: without it, an abandoned branch keeps offering its obsolete changes to every future merge, and someone eventually accepts them by accident. ## Legitimate uses **Retiring a superseded line of work.** A branch explored an approach that was rejected in favour of a different implementation on the mainline. Deleting the branch loses the record; merging it imports code you decided against. `-s ours` records the decision in the graph: this branch is accounted for, and its content is intentionally not here. **Stopping obsolete work from resurfacing.** A long-lived branch whose content was reimplemented rather than merged will otherwise conflict against the mainline forever. Recording it once with `-s ours` moves the merge base so only genuinely new commits are ever considered. **Repository consolidation.** When joining two histories where only one side's tree should survive, `-s ours` records the relationship without merging trees you do not want combined. ## The risk, stated plainly The merge is indistinguishable in `git log --oneline` from a merge that imported everything. A reviewer sees "Merge branch 'legacy-parser'" and reasonably assumes the content arrived. If that branch contained a security fix nobody had ported, it is now permanently excluded from consideration — future merges start after this point and will never offer it again. This is why the mitigations are procedural rather than technical: - **List first.** Run `git log --oneline <target>..<branch>` before merging and read what you are declining. - **Write the message.** The commit message is the only place the decision is recorded. State that content was intentionally not taken, and why. - **Verify after.** Comparing the merge's tree against its second parent shows exactly what was excluded; that diff is the review artefact. ## How to tell it apart from its neighbours - `-X ours` still merges — it takes all non-conflicting changes from the other branch and only decides contested hunks. Completely different blast radius. - `git merge --squash` imports the content but records no ancestry — the mirror image of `-s ours`, which records ancestry but no content. - Simply deleting the branch records neither. Being able to place `-s ours` in that grid is the strongest part of a good answer. ## The judgment an interviewer is probing This is a question about deliberately encoding a decision in history. The mature answer says: `-s ours` is not a conflict-resolution tool and must never be reached for because a merge was painful. It is a way of writing "we considered this branch and chose not to take it" into the DAG, and it is only defensible when that sentence is actually true, is stated in the commit message, and the content that was declined was reviewed rather than assumed to be worthless. A good candidate also names what they would do instead in the common case: if the branch has anything of value, port that first as ordinary commits, *then* record the rest with `-s ours` — so the strategy closes out only work that has genuinely been superseded.
- How would you audit what a -s ours merge discarded?Compare the merge commit's tree against its second parent — that difference is exactly what was not taken. Do the equivalent check beforehand by listing the incoming commits with `git log --oneline <target>..<branch>`, because after the merge the merge base has advanced and nothing will offer those changes again.
- What happens to future merges from a branch closed out with -s ours?The merge base moves to the recording merge, so later merges from that branch consider only commits made after it. That is the point of the technique — obsolete work stops being re-offered — and also its hazard, since anything valuable left behind is now permanently out of scope for merging.
- How is this different from just deleting the branch?Deleting removes the ref and records nothing; the fact that the work was considered and declined disappears, and if the branch exists elsewhere it will still merge as unmerged. `-s ours` writes the decision into the commit graph, which is what makes it durable and visible to everyone who clones the repository.
saying these in an interview costs you the question
- Reaches for -s ours to make a painful conflict go away
- Thinks -s ours keeps the other branch's non-conflicting changes
- Believes the discarded commits are deleted from the repository
- Assumes reviewers can see from the log that content was dropped
- Confuses it with squashing, which imports content but no ancestry