Introduction

When Git says two branches conflict, there are several different ways to "prefer one branch". The important part is choosing the right mechanism, because -X theirs, --theirs, and -s ours do not mean the same thing and can produce very different results.

Know What "Ours" and "Theirs" Mean

During a normal merge, ours means the branch you currently have checked out, and theirs means the branch you are merging in. If you are on main and run git merge feature, then:

• 'ours is main'
• 'theirs is feature'

That naming trips people up constantly. If you misunderstand it, you can keep the wrong side of the conflict and only notice after the merge is committed.

Prefer the Other Side Only for Conflicting Hunks

If you want Git to favor the incoming branch when a conflict happens, use the recursive merge strategy option:

git checkout main
git merge -X theirs feature

This does not mean "replace all files with the feature branch version." It only means that when Git encounters conflicting hunks, it chooses the theirs side automatically. Non-conflicting changes from both branches are still merged normally.

That makes -X theirs useful when most conflicts should lean toward the incoming branch, but you still want Git's standard merge behavior everywhere else.

Prefer a Specific File After a Conflict

If only a few files should come from one branch, it is usually better to merge normally and then pick the desired side on a per-file basis.

For the incoming branch version of one file:

git checkout --theirs path/to/file.txt
git add path/to/file.txt

For the current branch version:

git checkout --ours path/to/file.txt
git add path/to/file.txt

This is often the safest workflow because you can inspect the conflict first and then decide file by file instead of committing to a repo-wide preference rule.

Do Not Confuse -X theirs With -s ours

This is the most important distinction in the topic.

-X theirs:

• resolves conflicting hunks in favor of the other branch
• still incorporates non-conflicting changes from both branches

-s ours:

• records a merge commit
• ignores the other branch's content entirely
• keeps the current branch tree as the result

Example:

git checkout main
git merge -s ours feature

That command says, in effect, "mark feature as merged, but keep my current files exactly as they are." It is a specialized history-management tool, not a conflict-resolution shortcut.

Prefer One Side for a Whole Directory

Sometimes only a directory should come from one branch. In that case, merge first, then restore that path from the desired side.

1git merge feature
2git checkout --theirs docs/
3git add docs/
4git commit

This pattern is useful when generated files, documentation, or config directories should consistently favor one branch's state.

A Safe Workflow

If the merge matters, the safest approach is:

1. start the merge
2. inspect the conflicts
3. use --ours or --theirs only on the files that truly need it
4. review the staged diff before committing

Useful commands:

git status
git diff
git diff --staged

That is slower than blind automation, but it drastically reduces accidental data loss.

Common Pitfalls

The biggest mistake is misunderstanding ours and theirs. Those words are relative to the branch currently checked out, not emotionally tied to the branch you "like more".

Another common issue is expecting -X theirs to replace every conflicting file wholesale. It only affects conflicting sections, while ordinary non-conflicting changes from both branches are still merged.

People also misuse -s ours when they really wanted -X ours. The strategy option and the merge strategy are different tools with very different outcomes.

Finally, never skip reviewing the result. A merge command can complete successfully while still giving you the wrong semantic result for your codebase.

Summary

• 'ours is the checked-out branch and theirs is the branch being merged in.'
• Use git merge -X theirs branch to prefer the incoming side for conflicting hunks only.
• Use git checkout --theirs path or --ours path when resolving specific files.
• Do not confuse -X theirs with -s ours; they solve different problems.
• Review the merged result before committing, even if Git resolved conflicts automatically.