---
# === IDENTITY ===
id: software/debugging/git-merge-conflicts/2026
canonical_question: "What are the best strategies for resolving Git merge conflicts?"
aliases:
  - "git merge conflict"
  - "resolve git conflict"
  - "git merge vs rebase"
  - "git rerere"
  - "git conflict markers"
  - "git checkout --ours --theirs"
  - "git merge tool"
  - "git conflict resolution"
  - "git rebase conflict"
  - "merge conflict best practices"
entity_type: software_reference
domain: software > debugging > git_merge_conflicts
region: global
jurisdiction: global
temporal_scope: 2005-2026

# === VERIFICATION ===
last_verified: 2026-02-23
confidence: 0.95
freshness: yearly
version: 2.0
first_published: 2026-02-19

# === TEMPORAL VALIDITY ===
temporal_validity:
  status: stable
  last_breaking_change: "Git 2.50 — recursive strategy removed, ort is now the only backend"
  next_review: 2026-08-22
  change_sensitivity: low

# === CONSTRAINTS ===
constraints:
  - "Never commit with conflict markers (<<<<<<, =======, >>>>>>>) still in files — use git diff --check before every merge commit"
  - "During git rebase, ours/theirs semantics are reversed: --ours = upstream branch, --theirs = your feature branch commits being replayed"
  - "git merge -s ours is NOT the same as git merge -X ours — the former discards the entire other branch tree, the latter only resolves conflicts with HEAD"
  - "Binary files cannot be partially merged — you must choose --ours or --theirs entirely"
  - "Never force-push a rebased shared branch without explicit team agreement — it rewrites commit SHAs and breaks collaborators' work"
  - "Lock files (package-lock.json, yarn.lock, pnpm-lock.yaml) should be resolved by accepting one side and regenerating, not manually editing"

# === SKIP CONDITIONS ===
skip_this_unit_if:
  - condition: "User has a detached HEAD and wants to get back to a branch"
    use_instead: "software/debugging/git-detached-head/2026"
  - condition: "User has SSL/TLS certificate errors when pushing or pulling"
    use_instead: "software/debugging/ssl-tls-certificate-errors/2026"
  - condition: "User wants to understand Git branching strategies (GitFlow, trunk-based) rather than resolve conflicts"
    use_instead: "software/devops/git-branching-strategies/2026"

# === AGENT HINTS ===
inputs_needed:
  - key: operation_type
    question: "Are you in the middle of a merge or a rebase?"
    type: choice
    options: ["Merge", "Rebase", "Cherry-pick", "Not sure"]
  - key: conflict_complexity
    question: "How many files have conflicts?"
    type: choice
    options: ["1-2 files", "3-10 files", "10+ files"]
  - key: resolution_preference
    question: "Do you want to keep one side entirely, or combine changes from both?"
    type: choice
    options: ["Keep one side (ours/theirs)", "Combine changes manually", "Use a visual merge tool"]

# === DISTRIBUTION ===
canonical_source: "https://knowledgelib.io/software/debugging/git-merge-conflicts/2026"
suggested_citation: "Source: knowledgelib.io — AI Knowledge Library (verified 2026-02-23)"

# === RELATED UNITS ===
related_kos:
  related_to:
    - id: "software/debugging/git-detached-head/2026"
      label: "Git Detached HEAD"
    - id: "software/debugging/browser-cors-errors/2026"
      label: "Browser CORS Errors"
  solves:
    - id: "software/debugging/ssl-tls-certificate-errors/2026"
      label: "SSL/TLS Certificate Errors"
  often_confused_with:
    - id: "software/debugging/git-detached-head/2026"
      label: "Git Detached HEAD (different problem — not a merge conflict)"

# === SOURCES (5-8 authoritative sources) ===
sources:
  - id: src1
    title: "Git Documentation — git-merge"
    author: Git Project
    url: https://git-scm.com/docs/git-merge
    type: official_docs
    published: 2025-03-14
    reliability: authoritative
  - id: src2
    title: "Git Documentation — git-rerere"
    author: Git Project
    url: https://git-scm.com/docs/git-rerere
    type: official_docs
    published: 2025-03-14
    reliability: authoritative
  - id: src3
    title: "Atlassian — Git merge strategy"
    author: Atlassian
    url: https://www.atlassian.com/git/tutorials/using-branches/merge-strategy
    type: technical_blog
    published: 2024-06-01
    reliability: authoritative
  - id: src4
    title: "How Core Git Developers Configure Git"
    author: GitButler
    url: https://blog.gitbutler.com/how-git-core-devs-configure-git
    type: technical_blog
    published: 2025-01-15
    reliability: high
  - id: src5
    title: "Better Git Conflicts with zdiff3"
    author: Ductile Systems
    url: https://www.ductile.systems/zdiff3/
    type: technical_blog
    published: 2024-06-01
    reliability: high
  - id: src6
    title: "Pro Git Book — Advanced Merging"
    author: Scott Chacon, Ben Straub
    url: https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging
    type: official_docs
    published: 2024-01-01
    reliability: authoritative
  - id: src7
    title: "VS Code — Resolve merge conflicts (incl. AI-assisted)"
    author: Microsoft
    url: https://code.visualstudio.com/docs/sourcecontrol/merge-conflicts
    type: official_docs
    published: 2025-06-01
    reliability: high
  - id: src8
    title: "Git Documentation — merge-strategies (ort)"
    author: Git Project
    url: https://git-scm.com/docs/merge-strategies
    type: official_docs
    published: 2025-03-14
    reliability: authoritative
---

# What Are the Best Strategies for Resolving Git Merge Conflicts?

## TL;DR

- **Bottom line**: Merge conflicts occur when Git can't auto-reconcile divergent changes to the same lines, a deleted-vs-modified file, or a renamed file. The fastest resolution path is: identify conflicted files → open in editor → resolve conflict markers → `git add` → `git commit` (or `git rebase --continue`).
- **Key tool/command**: `git status` to list conflicted files; `git diff --diff-filter=U` to see all unmerged hunks; `git mergetool` to open a GUI resolver.
- **Watch out for**: Never commit with conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`) still in files — Git only checks for them if you configure `merge.conflictStyle`. Use `git diff --check` to catch stray markers before committing.
- **Works with**: Git 2.0+. The `zdiff3` conflict style requires Git 2.35+. The `ort` merge strategy (now default) requires Git 2.33+. As of Git 2.50, `recursive` is a synonym for `ort`.

## Constraints
<!-- Agents: read this section before recommending any action from this unit.
     These are hard constraints that must not be violated. -->

- **Never commit with conflict markers**: Always run `git diff --check` before committing a merge resolution. Stray `<<<<<<<` markers in production code cause syntax errors and silent data corruption.
- **ours/theirs semantics flip during rebase**: During `git merge`, `--ours` = your current branch (HEAD), `--theirs` = incoming. During `git rebase`, `--ours` = the upstream branch you're rebasing onto, `--theirs` = your commits being replayed. Getting this wrong silently discards the wrong side's changes.
- **`git merge -s ours` is destructive**: This merge *strategy* creates a merge commit but completely ignores the other branch's tree. It is not the same as `git merge -X ours` (a strategy *option* that only resolves conflicted hunks with HEAD). Confusing the two can silently discard an entire branch of work. [src1]
- **Binary files require full-side selection**: Git cannot partially merge binary files (images, compiled assets, PDFs). You must choose `--ours` or `--theirs` entirely. [src1]
- **Never force-push rebased shared branches**: Rebasing rewrites commit SHAs. Force-pushing a shared branch breaks every collaborator who has based work on the original commits. Only rebase branches that are purely local or explicitly marked as rebase-based.
- **Lock files must be regenerated, not manually edited**: Resolve `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`, `Pipfile.lock` by accepting one side and regenerating: `git checkout --theirs package-lock.json && npm install`. Manual edits to lock files produce invalid checksums.

## Quick Reference

| # | Scenario | Command / Solution | Notes |
|---|---|---|---|
| 1 | List all conflicted files | `git status` or `git diff --name-only --diff-filter=U` | Files marked `UU` (both modified) [src1] |
| 2 | Accept current branch for one file | `git checkout --ours <file>` | "Ours" = branch you're on (HEAD) [src1, src6] |
| 3 | Accept incoming branch for one file | `git checkout --theirs <file>` | "Theirs" = branch being merged in [src1, src6] |
| 4 | Accept ours for entire merge | `git merge -X ours <branch>` | Silently resolves all conflicts with HEAD version [src1, src3] |
| 5 | Accept theirs for entire merge | `git merge -X theirs <branch>` | Silently resolves all conflicts with incoming version [src1, src3] |
| 6 | Open GUI merge tool | `git mergetool` | Uses configured tool (VS Code, vimdiff, meld, etc.) [src1, src7] |
| 7 | Show common ancestor in markers | `git config merge.conflictStyle diff3` | Adds `\|\|\|\|\|\|\|` section with base version [src5, src6] |
| 8 | Use improved zdiff3 (recommended) | `git config --global merge.conflictStyle zdiff3` | Zealously removes common context from conflict markers (Git 2.35+) [src4, src5] |
| 9 | Enable rerere (auto-reuse resolutions) | `git config --global rerere.enabled true` | Records and replays conflict resolutions [src2] |
| 10 | Abort a merge | `git merge --abort` | Returns to pre-merge state [src1] |
| 11 | Abort a rebase | `git rebase --abort` | Returns to pre-rebase state [src1] |
| 12 | Continue after resolving rebase conflict | `git add <file> && git rebase --continue` | Move to next commit in rebase [src1] |
| 13 | Skip a conflicted commit during rebase | `git rebase --skip` | Drops the conflicting commit entirely [src1] |
| 14 | View conflict history | `git log --merge --oneline` | Shows commits that caused the conflict [src1] |
| 15 | AI-assisted resolution (VS Code) | Open conflicted file → "Resolve with Copilot" | Requires GitHub Copilot subscription; uses merge base as context [src7] |

## Decision Tree

```
START — Merge conflict encountered
├── Is this a merge or a rebase?
│   ├── MERGE → git status to find conflicted files
│   │   ├── Want to abort? → git merge --abort [src1]
│   │   ├── Accept entire side for all files?
│   │   │   ├── Keep HEAD (current branch) → git merge -X ours <branch> [src1, src3]
│   │   │   └── Keep incoming → git merge -X theirs <branch> [src1, src3]
│   │   └── Resolve file by file:
│   │       ├── One side clearly wins → git checkout --ours/--theirs <file> [src1, src6]
│   │       ├── Need to combine changes → edit file manually, remove markers [src6]
│   │       ├── Complex conflict → git mergetool (GUI) [src1, src7]
│   │       └── AI-assisted → VS Code "Resolve with Copilot" (experimental) [src7]
│   └── REBASE → conflicts appear per commit being replayed
│       ├── Want to abort? → git rebase --abort [src1]
│       ├── Resolve conflict in file → git add <file> → git rebase --continue [src1]
│       └── Skip this commit entirely? → git rebase --skip [src1]
├── After resolving each file:
│   ├── git add <resolved-file>
│   ├── Verify no stray markers → git diff --check [src1]
│   └── Finalize → git commit (merge) or git rebase --continue (rebase)
├── Lock file conflict? (package-lock.json, yarn.lock, etc.)
│   └── Accept one side → regenerate → git checkout --theirs package-lock.json && npm install [src6]
└── Recurring conflicts on same lines?
    └── Enable rerere → git config --global rerere.enabled true [src2]
```

## Step-by-Step Guide

### 1. Understand conflict markers

When a conflict occurs, Git inserts markers into the file. [src1, src5, src6]

```
<<<<<<< HEAD (current branch)
function greet(name) {
  return `Hello, ${name}!`;
}
||||||| base (common ancestor — only with diff3/zdiff3 style)
function greet(name) {
  return 'Hello, ' + name + '!';
}
======= (separator)
function greet(name, greeting = 'Hello') {
  return `${greeting}, ${name}!`;
}
>>>>>>> feature/greeting-improvements (incoming branch)
```

**Enable `zdiff3` style to see the common ancestor** (strongly recommended — used by Git core developers): [src4, src5]
```bash
# Git 2.35+ — zealously removes common context from markers
git config --global merge.conflictStyle zdiff3

# Older Git — still better than default
git config --global merge.conflictStyle diff3
```

**Verify**: `git config merge.conflictStyle` → expected output: `zdiff3`

### 2. Find and triage all conflicts

```bash
# All conflicted files
git status

# Only filenames of unmerged files
git diff --name-only --diff-filter=U

# See all conflict hunks at once
git diff

# Commits that contributed to the conflict
git log --merge --oneline --left-right
```

**Verify**: `git diff --name-only --diff-filter=U` → lists all files needing resolution

### 3. Resolve manually (most common path)

Edit each conflicted file, remove all conflict markers, and keep the correct code. [src1, src6]

```bash
# 1. Open each conflicted file in your editor
#    Remove <<<<<<, =======, >>>>>>> markers
#    Combine or choose the correct logic

# 2. Stage the resolved file
git add path/to/resolved-file.js

# 3. Verify no stray markers remain
git diff --check

# 4. Commit the merge
git commit
# Git auto-generates a merge commit message; edit as needed
```

**Verify**: `git diff --check` → empty output means no stray markers

### 4. Accept one side entirely (when appropriate)

When one side's changes are definitively correct: [src1, src3, src6]

```bash
# Accept current branch (HEAD) for one file
git checkout --ours src/config.json
git add src/config.json

# Accept incoming branch for one file
git checkout --theirs src/config.json
git add src/config.json

# During rebase: "ours" and "theirs" are swapped!
# In rebase: --ours = the upstream branch; --theirs = your feature branch
# Use git log --oneline to confirm which commit is being replayed
```

**Verify**: `git status` → file should show as staged (green), no longer UU

### 5. Use a merge tool

For complex conflicts, a visual three-way merge tool is much faster. [src1, src7]

```bash
# Configure VS Code as merge tool (includes 3-way merge editor)
git config --global merge.tool vscode
git config --global mergetool.vscode.cmd 'code --wait $MERGED'

# Configure vimdiff (terminal-based)
git config --global merge.tool vimdiff

# Other popular tools: meld, kdiff3, p4merge, opendiff (macOS)
git config --global merge.tool meld

# Launch merge tool for all conflicted files
git mergetool

# Launch for a specific file
git mergetool path/to/file.js

# Suppress .orig backup files
git config --global mergetool.keepBackup false
```

**Verify**: `git status` → all conflicted files should be resolved after mergetool exits

### 6. Enable rerere to avoid resolving the same conflict twice

`rerere` (Reuse Recorded Resolution) records how you resolved a conflict and replays it automatically in the future. [src2, src6]

```bash
# Enable globally
git config --global rerere.enabled true

# Also auto-stage rerere-resolved files
git config --global rerere.autoupdate true

# Verify rerere is working
git rerere status     # shows conflicts rerere is tracking
git rerere diff       # shows recorded resolution

# Where resolutions are stored
ls .git/rr-cache/    # each subdirectory = one recorded conflict

# Forget a bad recorded resolution
git rerere forget path/to/file.js
```

**Verify**: `git config rerere.enabled` → `true`

## Code Examples

### Script: automated conflict detection and summary

> Full script: [script-automated-conflict-detection-and-summary.sh](scripts/script-automated-conflict-detection-and-summary.sh) (32 lines)

```bash
#!/bin/bash
# Input:  Git repository with a merge/rebase in progress
# Output: Summary of all conflicts with context
echo "=== Git Conflict Summary ==="
echo "Repository: $(git rev-parse --show-toplevel)"
# ... (see full script)
```

### Python: pre-commit hook — detect conflict markers

> Full script: [python-pre-commit-hook-detect-conflict-markers.py](scripts/python-pre-commit-hook-detect-conflict-markers.py) (53 lines)

```python
#!/usr/bin/env python3
"""
Pre-commit hook to prevent committing with unresolved conflict markers.
Install: cp this_file .git/hooks/pre-commit && chmod +x .git/hooks/pre-commit
Input:  Git staged files
# ... (see full script)
```

### Git workflow: feature branch with clean rebase

> Full script: [git-workflow-feature-branch-with-clean-rebase.sh](scripts/git-workflow-feature-branch-with-clean-rebase.sh) (40 lines)

```bash
#!/bin/bash
# Input:  feature branch and target branch (default: main)
# Output: Clean linear history via rebase, then FF merge
FEATURE_BRANCH="${1:-$(git branch --show-current)}"
TARGET_BRANCH="${2:-main}"
# ... (see full script)
```

## Anti-Patterns

### Wrong: Resolving rebase conflicts by accepting "ours" when you mean your feature branch

```bash
# ❌ BAD — "ours" during rebase means the UPSTREAM branch, not your feature [src1, src6]
# You're on feature/my-feature, rebasing onto main
git rebase main
# Conflict appears...
git checkout --ours conflicted-file.js  # ← This keeps main's version, NOT your feature!
git add conflicted-file.js
git rebase --continue
# Your feature changes are silently lost!
```

### Correct: During rebase, "theirs" is your feature branch

```bash
# ✅ GOOD — in rebase context, understand the ours/theirs flip [src1, src6]
# Rebasing feature onto main:
#   --ours   = main (the base being rebased onto)
#   --theirs = your feature branch commit being replayed

# To keep YOUR feature branch changes during rebase:
git checkout --theirs conflicted-file.js
git add conflicted-file.js
git rebase --continue

# When confused: inspect both versions explicitly
git show :2:conflicted-file.js  # "ours" (main)
git show :3:conflicted-file.js  # "theirs" (feature commit)
```

### Wrong: Committing without verifying conflict markers are gone

```bash
# ❌ BAD — committing with stray conflict markers in code [src1, src6]
# Accidental commit with <<<<<<< still in file
git add src/utils.js
git commit -m "resolve conflict"
# Now conflict markers are in production code!
```

### Correct: Always run git diff --check before committing

```bash
# ✅ GOOD — verify no markers remain before committing [src1, src6]
# After resolving all conflicts:
git diff --check
# If output is empty → safe to commit
# If output shows markers → fix those files first

# Automate: add pre-commit hook (see code example above)
# Or use: git config core.whitespace conflict-marker-size=7
```

### Wrong: Using `git merge -X theirs` when only some files should accept theirs

```bash
# ❌ BAD — silently overwrites all conflicts with one side [src1, src3]
git merge -X theirs feature/big-refactor
# ALL conflicted files are resolved with "theirs" — even ones you wanted to keep
# No way to review individual decisions after the fact
```

### Correct: Use -X strategies only for wholesale merges; resolve per-file otherwise

```bash
# ✅ GOOD — targeted per-file resolution with review [src1, src3]
git merge feature/big-refactor   # let it conflict

# Then for each file, make an intentional decision:
git checkout --theirs src/api/client.js    # their refactor is better
git checkout --ours   src/config/env.js    # keep our environment config
# Manually resolve: src/utils/helpers.js   # both sides have useful changes

git add src/api/client.js src/config/env.js src/utils/helpers.js
git diff --check
git commit
```

### Wrong: Using default conflict style without common ancestor context

```bash
# ❌ BAD — default conflict style shows only two sides [src4, src5]
# Without diff3/zdiff3, you can't see what the original code looked like:
<<<<<<< HEAD
const timeout = 5000;
=======
const timeout = 10000;
>>>>>>> feature/performance
# Was it 3000 before? 5000? You don't know — forced to guess.
```

### Correct: Configure zdiff3 globally to see the base version

```bash
# ✅ GOOD — zdiff3 shows the common ancestor with minimized noise [src4, src5]
git config --global merge.conflictStyle zdiff3

# Now conflicts show:
<<<<<<< HEAD
const timeout = 5000;
||||||| base
const timeout = 3000;
=======
const timeout = 10000;
>>>>>>> feature/performance
# Now you can see both sides changed from 3000 — make an informed decision.
```

## Common Pitfalls

- **`ours`/`theirs` meaning flips during rebase**: During `git merge`, `ours` = your current branch, `theirs` = incoming. During `git rebase`, `ours` = the upstream branch you're rebasing onto, `theirs` = your commits being replayed. This trips up even experienced developers. [src1, src6]
- **Default conflict style hides the base**: Without `merge.conflictStyle zdiff3`, you only see two sides. The common ancestor is hidden. Enabling `zdiff3` (Git 2.35+) often makes the correct resolution obvious. Git core developers use zdiff3 by default. [src4, src5]
- **Long-lived branches accumulate conflicts**: The longer a branch diverges from `main`, the more conflicts accumulate. Keeping branches short-lived (< 1 week) and rebasing daily dramatically reduces conflict complexity. [src3]
- **`git rerere` not enabled by default**: This powerful feature is off by default. Enable it globally (`rerere.enabled true`) to avoid resolving the same conflict pattern repeatedly during complex rebases. Use `--no-rerere-autoupdate` if you want to review rerere's resolutions before they're staged. [src2, src4]
- **Backup files from mergetool**: By default, `git mergetool` creates `.orig` backup files. Set `mergetool.keepBackup false` globally to suppress them, then add `*.orig` to `.gitignore` as a safety net. [src1, src7]
- **Forgetting to `git add` after manual resolution**: After editing a conflicted file, you must `git add` it to mark it as resolved. Just saving the file is not enough — Git still considers it conflicted until it's staged. [src1, src6]
- **`recursive` strategy removed in Git 2.50**: As of Git 2.50, the `recursive` merge strategy is a synonym for `ort`. If your CI scripts or Git hooks reference `-s recursive` explicitly, they still work but are redirected to `ort`. New scripts should use `ort` directly. [src8]

## Diagnostic Commands

> Full script: [diagnostic-commands.sh](scripts/diagnostic-commands.sh) (31 lines)

```bash
# === Find conflicts ===
git status                              # shows files with UU (unmerged) status
git diff --name-only --diff-filter=U   # only conflicted filenames
git diff                                # full diff of all unresolved hunks
git log --merge --oneline --left-right # commits that contributed to conflicts
# ... (see full script)
```

## Version History & Compatibility

| Version / Feature | Available Since | Notes |
|---|---|---|
| `git rerere` | Git 1.5.4 | Enable with `rerere.enabled true` [src2] |
| `merge.conflictStyle diff3` | Git 1.6.1 | Shows common ancestor in conflict markers [src5] |
| `merge.conflictStyle zdiff3` | Git 2.35 (Jan 2022) | Improved diff3 — zealously removes common context from markers [src4, src5] |
| `git checkout --ours/--theirs` | Git 1.6.1 | Per-file resolution [src1] |
| `git merge -X ours/theirs` | Git 1.7.0 | Whole-merge strategy option [src1] |
| `git mergetool` | Git 1.5.1 | Launch configured merge tool [src1] |
| `git merge --abort` | Git 1.7.4 | (Before: `git reset --merge`) [src1] |
| `git rebase --abort` | Git 1.7.8 | Safely cancel a rebase [src1] |
| `ort` merge strategy (default) | Git 2.33 (Aug 2021) | Faster replacement for `recursive`; handles renames better [src8] |
| `recursive` → `ort` redirect | Git 2.50 (2025) | `recursive` is now a synonym for `ort` [src8] |
| VS Code AI-assisted merge | VS Code 1.105 (2025) | Requires GitHub Copilot subscription [src7] |

## When to Use / When Not to Use

| Use Strategy | When | Why |
|---|---|---|
| `git merge` | Shared/public branches | Preserves full history; safe for collaborators [src3] |
| `git rebase` | Private feature branches | Linear history; cleaner PR diffs [src3] |
| `git merge -X ours/theirs` | Auto-generated files (e.g., lock files, changelogs) | One side is definitively correct [src1, src3] |
| `rerere` | Frequent rebases; long-lived branches | Avoid re-resolving the same conflict [src2] |
| `zdiff3` style | Always | More context = better resolution decisions; recommended by Git core developers [src4, src5] |
| `git mergetool` | Complex multi-hunk conflicts | Visual three-way merge is faster than manual editing [src7] |
| AI-assisted (VS Code Copilot) | Conflicts with clear intent on both sides | AI considers merge base + both branches; experimental, review output carefully [src7] |

## Important Caveats

- **Never force-push a rebased shared branch without team agreement**: Rebasing rewrites commit SHAs. If teammates have based work on the original commits, force-pushing will cause them major problems. Only rebase branches that are purely local or clearly marked as regularly rebased.
- **`git merge -X ours` is not `git merge -s ours`**: The `-X ours` flag is a merge strategy *option* (resolves conflicts with HEAD). The `-s ours` flag is a merge *strategy* (creates a merge commit but completely ignores the other branch's changes — its tree is not incorporated at all). The latter is rarely what you want. [src1]
- **Lock files and generated files always conflict**: Handle `package-lock.json`, `yarn.lock`, `Pipfile.lock`, `pnpm-lock.yaml` by accepting one side and regenerating: `git checkout --theirs package-lock.json && npm install`.
- **Binary file conflicts**: Git cannot auto-resolve binary file conflicts. You must choose `--ours` or `--theirs` entirely. There are no partial resolutions for binary files. [src1]
- **Squash merges lose `rerere` history**: If your workflow squash-merges PRs, the individual commit SHAs change and `rerere` cache entries become stale. Consider whether `rerere` fits your workflow. [src2]
- **`ort` strategy differences**: The `ort` merge strategy (default since Git 2.33, sole backend since 2.50) handles rename detection better than the old `recursive` strategy but may produce different conflict markers for edge cases involving directory renames. If you see unexpected conflicts after upgrading, check `git log --diff-filter=R` for renames. [src8]

## Related Units

- [Git Detached HEAD](/software/debugging/git-detached-head/2026)
- [Browser CORS Errors](/software/debugging/browser-cors-errors/2026)
- [SSL/TLS Certificate Errors](/software/debugging/ssl-tls-certificate-errors/2026)