Introduction

In Git conflict resolution, ours and theirs do not mean "my code" and "someone else's code" in a social sense. They mean two specific sides of Git's current operation. During a normal merge, ours is the version from HEAD, and theirs is the version from the branch being merged in. During rebase and cherry-pick, the meaning can feel inverted because the operation context is different.

The Normal Merge Meaning

Suppose you are on main and run:

git merge feature

If a conflict happens:

• 'ours means the version from your current HEAD, which is main'
• 'theirs means the version from feature, the branch being merged into main'

That is the core definition during a merge.

If you resolve a conflicted file with:

git checkout --ours path/to/file

Git writes the HEAD side into the working tree.

If you run:

git checkout --theirs path/to/file

Git writes the incoming branch's version instead.

Why The Words Make Sense In A Merge

Git is speaking from the point of view of the branch currently checked out.

• 'ours: the branch we are on'
• 'theirs: the branch being merged into us'

That is why the names are about operation context, not authorship.

If you authored the incoming branch yourself, it is still theirs during that merge. If someone else authored the current branch, it is still ours while you are merging from it.

The Rebase And Cherry-Pick Trap

This is where many developers get confused.

During a rebase, Git is replaying your commits onto another base. In conflict resolution commands, ours and theirs refer to the state inside that rebase machinery, not to your emotional sense of ownership.

In practice, during a rebase conflict:

• 'ours is usually the branch you are rebasing onto'
• 'theirs is usually the commit being replayed'

That feels backwards if you think "my branch should be ours." But Git is not using a human team perspective. It is using the current operation's internal merge stages.

That is why many people say:

• merge: ours means current branch
• rebase: ours often looks like the upstream base

If you do not keep the operation type in mind, you will choose the wrong side.

--ours And --theirs Versus -Xours

These are related, but not identical.

git checkout --ours file and git checkout --theirs file are conflict-resolution actions on a specific file.

git merge -X ours is a merge option telling Git how to favor one side automatically when a merge conflict arises. It is not the same as the ours merge strategy.

That distinction matters because people often confuse:

• the ours and theirs file versions during conflict resolution
• the -X ours merge option
• the -s ours merge strategy

-s ours Is Different Again

The ours merge strategy means: record a merge commit but ignore the other branch's tree content entirely.

That is not normal conflict resolution. It is a special strategy choice with much broader consequences.

So these are three different concepts:

• '--ours and --theirs: choose a file version in a conflict'
• '-X ours: prefer our side when resolving content conflicts'
• '-s ours: keep our whole tree and ignore the other side's tree'

They sound similar but operate at different levels.

A Practical Way To Stay Oriented

When a conflict appears, ask two questions:

1. what operation am I in: merge, rebase, or cherry-pick
2. what does Git consider HEAD and the other side right now

That mental reset prevents most mistakes.

You can also inspect conflict markers in the file and use Git status to confirm the operation before choosing sides.

Example Walkthrough

Normal merge:

git switch main
git merge feature

Conflict occurs in app.py.

• 'git checkout --ours app.py keeps main's version'
• 'git checkout --theirs app.py keeps feature's version'

Now compare with rebase:

git switch feature
git rebase main

If conflict occurs, --ours and --theirs refer to the rebase conflict stages, which often means main becomes the ours side and the replayed feature commit becomes the theirs side.

That is the subtle but important difference.

Common Pitfalls

• Thinking ours means "the code I personally wrote."
• Forgetting that ours and theirs are operation-relative, not author-relative.
• Assuming merge and rebase use the terms in the same intuitive way.
• Confusing git checkout --ours with git merge -X ours.
• Confusing the ours merge strategy -s ours with ordinary conflict resolution choices.

Summary

• In a normal merge, ours is the current HEAD branch and theirs is the branch being merged in.
• In rebase and cherry-pick flows, the meaning can appear inverted because the operation context changes.
• '--ours and --theirs are file-level conflict choices.'
• '-X ours and -s ours are different mechanisms and should not be treated as synonyms.'
• Always interpret the terms relative to Git's current operation, not relative to who wrote the code.