Merge Strategies — ours, theirs, recursive

When you run git merge, Git does not always combine changes the same way. It selects a merge strategy based on the situation, and you can override that choice. Understanding the available strategies gives you fine-grained control over how branches are combined.

The Default: Recursive Strategy

For most two-branch merges, Git uses the recursive strategy. It finds the common ancestor of both branches and performs a three-way merge, creating a merge commit if the branches have diverged.

git merge feature
# Equivalent to:
git merge --strategy=recursive feature

The recursive strategy handles most cases well, including situations where there are multiple common ancestors (it merges the ancestors recursively to create a virtual base).

Strategy Options: -X ours and -X theirs

The recursive strategy accepts options that control how conflicts are resolved:

git merge -X ours feature
git merge -X theirs feature

• -X ours — When a conflict occurs, automatically pick our version (the current branch)
• -X theirs — When a conflict occurs, automatically pick their version (the branch being merged)

Non-conflicting changes from both sides are still merged normally. These options only affect lines where both branches made different changes to the same place.

The ours Strategy (Not the Same!)

There is a completely different strategy called ours:

git merge --strategy=ours feature

This creates a merge commit but completely ignores the other branch's changes. The result is identical to the current branch's content. The other branch is recorded as a parent (so Git knows it was "merged"), but none of its changes are applied.

The Critical Difference

The first is a conflict-resolution preference. The second is a way to mark a branch as merged without taking any of its content.

When is --strategy=ours Useful?

• Retiring a branch you never want to merge but want to mark as "done"
• Establishing that your branch supersedes another without incorporating its changes
• Preventing future merges from re-introducing changes from that branch

The theirs Strategy

There is no built-in --strategy=theirs, but you can achieve the same effect:

git merge -s ours feature    # marks feature as merged, keeps our content
# To do the opposite (keep theirs entirely):
git merge -X theirs feature  # merges, resolving all conflicts in their favor

For a true "theirs strategy" (discard our changes entirely), you would need a manual approach or use git merge -X theirs which is close enough for most cases.

Octopus Merge

When you need to merge more than two branches at once, Git uses the octopus strategy:

git merge feature-a feature-b feature-c

Git automatically selects the octopus strategy when multiple branches are listed. It works well when the branches do not conflict with each other — for example, when different teams worked on completely separate files.

Octopus merges cannot handle conflicts. If any branch conflicts with another, Git aborts and asks you to merge them one at a time.

After an octopus merge:
main:     A --- B ----------- M
                 \    \      /|
feature-a:        C    \   /  |
feature-b:         D    \/   |
feature-c:          E ---+---

The merge commit M has multiple parents — one for each merged branch.

Summary

Key Insight

The most common source of confusion is --strategy=ours vs -X ours. Remember: the strategy decides the overall algorithm, while -X options fine-tune conflict resolution within that algorithm. When someone says "merge with ours," always ask which one they mean.