Introduction

If you want Git to resolve a conflict by keeping the version from the current branch, the key concept is “ours.” During a normal merge, “ours” means the branch you currently have checked out, while “theirs” means the branch being merged in. You can apply that choice to individual files, or you can ask Git to prefer your side automatically for conflicting hunks during the merge.

Resolve a Conflicted File by Keeping the Current Branch Version

After Git reports a conflict, you can take the version from the branch you are on with:

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

Modern Git also supports:

git restore --ours path/to/file
git add path/to/file

This does two things:

1. it replaces the working copy of that file with the conflicted file from the current branch
2. it stages the result as the chosen resolution once you run git add

That is the most direct way to say “for this file, keep my branch’s version.”

Resolve All Conflicted Files the Same Way

If every conflicted file should keep the current branch version, you can apply the same pattern to all conflicts:

git checkout --ours .
git add .

Be careful with this. It is fast, but it discards the incoming side of every conflicted file in the current directory tree. That is appropriate only when you are sure that is the intended outcome.

Prefer “Ours” Automatically During Merge

If you already know before merging that any conflicting hunks should prefer the current branch, use the recursive merge strategy option:

git merge -X ours other-branch

This is a useful distinction:

• non-conflicting changes from other-branch are still merged
• only conflicting hunks prefer the current branch

That makes -X ours much safer than throwing away the other branch entirely.

Do Not Confuse -X ours With -s ours

These two commands are very different:

git merge -X ours other-branch
git merge -s ours other-branch

-X ours means “merge normally, but if a hunk conflicts, keep my side.”

-s ours means “record a merge commit that ignores the other branch’s content completely.” That strategy is much more extreme and is not what most people want when they say “take the current branch version on conflicts.”

A Concrete Example

Suppose you are on main and merging feature-x:

git switch main
git merge feature-x

Git reports a conflict in config.json. To keep the main version:

git checkout --ours config.json
git add config.json
git commit

If you want that behavior built into the merge command itself:

git switch main
git merge -X ours feature-x

Now only conflicting hunks prefer main, while non-conflicting changes from feature-x still come across.

Rebase Changes the Mental Model

The words “ours” and “theirs” get more confusing during a rebase. In a rebase conflict, the labels are based on the temporary merge state Git is constructing, not on the branch names in the way people naturally expect.

That means you should be extra careful when using --ours or --theirs during rebase. If you are unsure, inspect the conflict markers or use git status and git diff before resolving automatically.

For ordinary merge workflows, though, “ours” usually matches the checked-out current branch, which is what this article is targeting.

When Automatic Resolution Is Appropriate

Automatically taking the current branch version makes sense when:

• generated files should always come from the current branch
• one side contains authoritative configuration
• the incoming branch is known to touch files in a way you want to ignore on conflict

It is not a substitute for understanding the logical effect of the merge. Git can resolve text conflicts mechanically, but it cannot tell whether the resulting code still makes sense.

Common Pitfalls

The biggest pitfall is confusing -X ours with -s ours. The first prefers your side only on conflicting hunks. The second ignores the other branch’s content entirely.

Another common mistake is running git checkout --ours . too broadly and discarding useful incoming changes from many files at once.

Rebase workflows are another source of confusion because ours and theirs do not always map to the branch names the way people expect. Double-check before applying a blanket resolution.

Finally, remember that choosing “ours” only solves the textual conflict. It does not guarantee the final code is logically correct, so review the result before moving on.

Summary

• Use git checkout --ours <file> or git restore --ours <file> to keep the current branch version of a conflicted file.
• Run git add afterward to mark the conflict as resolved.
• Use git merge -X ours other-branch to prefer the current branch only for conflicting hunks.
• Do not confuse -X ours with -s ours.
• Automatic conflict resolution is useful, but you still need to verify the merged code is correct.