Git

Git Merge Strategy Options: "ours" vs "theirs" in Conflict Resolution

· by DebuggedIt

Quick answer

"ours" and "theirs" mean genuinely different things depending on which specific Git command and context you're using them in — the same words are reused across...

"ours" and "theirs" mean genuinely different things depending on which specific Git command and context you're using them in — the same words are reused across several distinct mechanisms, and confusing them is a common, easy mistake that can silently resolve conflicts in exactly the opposite direction from what you actually intended.

The Problem

Attempting to resolve a conflict by favoring one side entirely, but the result ends up with the wrong side's changes:

git merge --strategy-option ours feature-branch
# expected to keep my current branch's version, but the result is confusing

Or, during a rebase specifically, "ours" and "theirs" appear to behave in a way that seems backwards compared to a regular merge.

"ours" and "theirs" flip during rebase git merge ours = current branch (HEAD) git rebase ours = the branch being rebased ONTO

Why It Happens

The confusion is genuinely well-founded, because Git's own behavior for these terms differs across contexts:

  • During a normal git merge, "ours" refers to your current branch (whatever HEAD currently points to before the merge), and "theirs" refers to the branch you're merging in
  • During a git rebase, because a rebase internally works by replaying your commits on top of the target branch one at a time, "ours" actually refers to the branch you're rebasing onto (the target), and "theirs" refers to your own original commits being replayed — this is effectively the reverse of what "ours"/"theirs" mean during a normal merge, and is the single most common source of this specific confusion
  • git checkout --ours/--theirs during an active conflict resolution follows whichever of the above meanings applies to the operation currently in progress (merge or rebase), inheriting that operation's specific definition rather than having its own independent meaning

The Fix

For a normal merge, if you want to entirely favor your current branch's version wherever conflicts occur:

git merge -X ours feature-branch

To entirely favor the incoming branch's version instead:

git merge -X theirs feature-branch

For resolving individual conflicted files during an active merge conflict, rather than applying a strategy to the entire merge:

git checkout --ours path/to/file.txt   # keep your current branch's version of this file
git checkout --theirs path/to/file.txt # keep the incoming branch's version of this file
git add path/to/file.txt

For a rebase specifically, remember the meanings are effectively swapped — if you want to favor the branch you're rebasing onto (the target) during conflicts:

git rebase -X ours origin/main

And if you want to favor your own commits' changes (the ones being replayed) during a rebase's conflicts:

git rebase -X theirs origin/main

Given how genuinely easy this is to get backwards, especially during a rebase, it's often safer and more reliable to resolve conflicts manually, reviewing each conflicted file directly, rather than relying on a blanket "ours"/"theirs" strategy — this is particularly true for rebases specifically, where the swapped meaning makes it easy to confidently apply the wrong strategy option while believing you've made the correct choice:

# Manual review avoids any ambiguity about which side "ours"/"theirs" refers to
git status
# open and manually review each conflicted file directly

If you do use a blanket strategy option, verify the result matches your actual intent immediately afterward, before completing the merge or rebase, by reviewing the affected files' actual final content:

git diff HEAD~1  # or appropriate comparison, to confirm the resolution matches what you expected

Still Confused?

A reliable mental shortcut: think of "ours" and "theirs" as referring to whichever side of history is currently being kept stable versus which side is being replayed or merged in — during a normal merge, your current branch stays put while the other branch's commits get merged in, so "ours" is the stable side. During a rebase, your own commits are the ones being picked up and replayed elsewhere, while the target branch stays put, so "ours" refers to that stable target instead. If this framing still feels ambiguous in the moment, defaulting to manual conflict resolution removes any need to rely on correctly remembering this distinction under pressure.