Git Merge Strategies — The 'Wrong' Strategy Caused Silent Data Loss

Most developers never think about merge strategies. Git's default 'ort' strategy handles 99% of merges automatically. But when it gets the 1% wrong, the results are silent and catastrophic: files that disappear without a conflict, renamed code that's treated as deleted and recreated, and merge commits that look clean but contain wrong code. The incident that triggered this guide: a team lost 40 renamed files because the default strategy didn't detect the renames. This guide covers when to override the default, the strategy options Git provides, and how to prevent silent merge corruption.

Available Merge Strategies and When to Use Them

Git provides several merge strategies via -s <strategy>:

• ort (default since Git 2.33): Replaced 'recursive'. Faster, handles renames better, uses less memory. Handles 99% of merges.
• recursive: The previous default. Use -s recursive with -X options for fine control.
• resolve: Two-way merge. Fast but can't handle complex histories. Rarely needed.
• octopus: Merges more than two branches at once. Used for git merge feature1 feature2 feature3.
• ours: Keeps your branch's files entirely. The other branch's changes are recorded as merged but don't affect files.
• subtree: For merging a subproject into a subdirectory.

The -X options for recursive/ort: patience (better diff quality), ignore-space-change, renormalize, no-renames, rename-threshold=<N>.

# Default merge (ort strategy)
git merge feature-branch

# Explicit recursive with patience diff
git merge -s recursive -X patience feature-branch

# Keep our version on conflicts
git merge -X ours feature-branch

# Accept their version on conflicts
git merge -X theirs feature-branch

# Merge with custom rename threshold
git merge -X rename-threshold=30 feature-branch

# Ours strategy (discard all incoming changes)
git merge -s ours feature-branch -m 'Merge feature (keeping our files)'

# Octopus merge (3+ branches)
git merge feature-a feature-b feature-c