Introduction

Git's merge system has three layers that developers often conflate: the merge algorithm (how Git computes what changed), the conflict format (how Git displays unresolvable differences in your files), and mergetools (external programs that help you resolve conflicts). Understanding each layer separately clears up most merge confusion. The algorithm decides what conflicts exist, the format controls what you see in the file, and the mergetool provides a visual interface to pick the right resolution.

Merge Algorithms

Git supports several merge strategies, each with its own algorithm for combining changes:

Recursive (default for two branches)

git merge feature
# Uses the "recursive" strategy by default

The recursive strategy finds the common ancestor of both branches and performs a three-way merge. If there are multiple common ancestors (criss-cross merges), it recursively merges the ancestors first to create a virtual base. This handles most cases correctly.

ORT (Ostensibly Recursive's Twin, Git 2.33+)

git -c merge.strategy=ort merge feature

ORT is a rewrite of the recursive strategy that is faster and handles edge cases (directory renames, file/directory conflicts) more correctly. It became the default in Git 2.34+.

Octopus (default for 3+ branches)

git merge feature1 feature2 feature3
# Uses octopus strategy — cannot handle conflicts

Ours

git merge -s ours feature
# Keeps our version entirely, ignores their changes

Conflict Format: merge vs diff3

When Git cannot auto-merge, it writes conflict markers into the file. The default format shows two sides:

Default (merge) Format

1<<<<<<< HEAD
2console.log("Hello from main");
3=======
4console.log("Hello from feature");
5>>>>>>> feature

You see what HEAD has and what the feature branch has, but not what the common ancestor had. This makes it hard to understand the intent of each change.

diff3 Format (Recommended)

git config --global merge.conflictstyle diff3

1<<<<<<< HEAD
2console.log("Hello from main");
3|  |  |  |  |  |  | merged common ancestors console.log("Hello"); ======= console.log("Hello from feature"); >>>>>>> feature ``` The ` |  |  |  |  |  |  |
4| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
5| `$LOCAL` | Our version (HEAD) |
6| `$REMOTE` | Their version (the branch being merged) |
7| `$BASE` | Common ancestor |
8| `$MERGED` | The file with conflict markers (your working copy) |
9
10## How They Interact
11

1. You run: git merge feature
2. Git picks the merge ALGORITHM (recursive/ort)
3. Algorithm finds conflicts it cannot auto-resolve
4. Git writes conflict MARKERS in the FORMAT you configured (merge/diff3/zdiff3)
5. You either: a. Edit the file manually (read the markers, fix, save) b. Run git mergetool → opens the MERGETOOL with LOCAL/REMOTE/BASE/MERGED
6. Mark resolved: git add file.js
7. Complete: git merge --continue

1
2The algorithm and format are independent — `diff3` format works with any strategy. The mergetool reads the conflict markers or the separate file versions, depending on the tool.
3
4## Manual Resolution Workflow
5
6```bash
7# 1. Merge and see conflicts
8git merge feature
9# Auto-merging app.js
10# CONFLICT (content): Merge conflict in app.js
11
12# 2. Open the file — see conflict markers
13cat app.js
14
15# 3. Edit to resolve (remove markers, keep correct code)
16vim app.js
17
18# 4. Stage the resolved file
19git add app.js
20
21# 5. Complete the merge
22git merge --continue

Recommended Configuration

1# Use diff3 for better context in conflict markers
2git config --global merge.conflictstyle zdiff3
3
4# Set your preferred mergetool
5git config --global merge.tool vscode
6
7# Don't keep .orig backup files after mergetool
8git config --global mergetool.keepBackup false
9
10# Use patience diff for better conflict detection
11git config --global diff.algorithm patience

Common Pitfalls

• Not using diff3/zdiff3: The default two-way conflict format hides the common ancestor, making it impossible to understand the intent of each change. Always enable diff3 or zdiff3.
• Confusing strategy with format: Changing merge.conflictstyle does not change how Git computes the merge. It only changes how conflicts are displayed. The algorithm (recursive, ort) is a separate setting.
• Mergetool .orig files: By default, git mergetool creates .orig backup files. These clutter your repo and get accidentally committed. Set mergetool.keepBackup false.
• Aborting a merge incorrectly: Use git merge --abort to cleanly cancel a merge in progress. Do not git checkout . or git reset --hard during a merge — these may leave the repo in an inconsistent state.
• Assuming the mergetool resolves automatically: Mergetools present the conflict visually but you still choose the resolution. Closing the tool without editing marks the file as resolved with whatever content it had, potentially keeping conflict markers.

Summary

• Merge algorithms (recursive, ort, octopus) determine how Git combines changes and detects conflicts
• Conflict format (merge, diff3, zdiff3) controls what you see in conflict markers — use zdiff3 for the best experience
• Mergetools (VS Code, vimdiff, IntelliJ) provide visual interfaces for resolving conflicts using LOCAL, REMOTE, BASE, and MERGED files
• These three layers are independent — configure each separately
• Always enable diff3 or zdiff3 to see the common ancestor in conflict markers