Git Merge Strategies Explained

In One Sentence

Git's merge strategy determines the algorithm Git uses to compute the final content when integrating two branches. Choosing the right strategy avoids unnecessary conflicts and history noise.

Before

main

ABC

feature

BDE

git merge

After

main

ABCM

feature

BDEM

Merge Strategy Overview

Git supports these merge strategies:

ort

The current default merge strategy, introduced in Git 2.33 to replace recursive.

How It Works

1. Find the merge base (common ancestor) of the two branches
2. Compute changes from both branches relative to the merge base
3. Apply a more efficient three-way merge algorithm
4. Detect and handle renames, permission changes, etc.

Advantages Over recursive

• Much faster (rewritten in C vs the original Python/Shell logic)
• More accurate conflict detection
• More reliable rename detection
• Lower memory usage

Usage

# ort is the default — no need to specify
git merge feature/login

# explicit
git merge -s ort feature/login

recursive

The default before Git 2.33, now superseded by ort but still available for compatibility.

How It Works

When two branches have multiple common ancestors, recursive merges them into a virtual ancestor first:

main:    A---B---C---D
              \
feature:       E---F

If the merge base is not unique, recursive first recursively merges the ancestors before performing the merge.

Configuration Options

# use recursive strategy explicitly
git merge -s recursive feature/login

# set rename similarity threshold
git merge -s recursive -X find-renames=70 feature/login

# ignore whitespace changes
git merge -s recursive -X ignore-space-change feature/login

# use their version on conflicts
git merge -s recursive -X theirs feature/login

# use our version on conflicts
git merge -s recursive -X ours feature/login

octopus

Merges multiple branches at once.

How It Works

Applies each branch sequentially onto the current branch. If any individual merge produces a conflict, octopus aborts immediately — it is not designed for conflict resolution.

Usage

# merge three feature branches at once
git merge feature/login feature/payment feature/report

Git automatically selects octopus when merging more than two branches.

When to Use

• Batch-merging multiple independent, conflict-free feature branches
• Topic branch rollups
• Release branch aggregation

When to Avoid

• Branches with overlapping code changes
• When fine-grained conflict control is needed

ours

Completely ignores all changes from the merged branches — the result is exactly the current branch content. The history records that those branches were "merged."

Usage

# mark feature/experimental as merged without applying its changes
git merge -s ours feature/experimental

When to Use

• Deprecating a feature branch while preserving history
• Changes were applied through other means but you want a merge record
• Marking that a branch has been "overridden"

ours vs -X ours

Important distinction:

• -s ours: the entire merge result equals current branch content
• -X ours (with recursive/ort): resolves conflicts by preferring current branch, but non-conflicting changes are still applied

subtree

Merges content from the target branch into a subdirectory of the current repository.

How It Works

Automatically detects which subdirectory the merged content belongs in and maps changes accordingly.

Usage

# merge a library repo into the lib/ subdirectory
git merge -s subtree lib/main

When to Use

• Integrating an independent library as a subtree
• Maintaining subprojects alongside the main codebase

How to Choose

Daily Development

Use the default (ort) with no special configuration:

git switch main
git merge feature/login

Batch Merging

Use octopus:

git merge feature/a feature/b feature/c

Special Cases

# ignore whitespace differences during merge
git merge -X ignore-all-space feature/login

# fully accept their version on conflicts
git merge -X theirs feature/login

# record merge relationship without content changes
git merge -s ours feature/abandoned

!Don't Change Merge Strategies on Shared Branches Without Thought

Use the default strategy (ort) for daily development. Avoid non-default strategies like -s ours or -X theirs on shared production branches unless you fully understand the side effects. In particular, -s ours completely ignores all changes from the merged branch — it's meant for deprecating branches, not daily work.

Strategy Options Reference

Continue Learning

After understanding merge strategies, continue with:

1. git merge command reference and full options
2. Merge vs Rebase decision framework
3. Three-way merge internals
4. Conflict resolution strategies and tools