Git: CONFLICT (content) — merge conflict in file
CONFLICT — merge conflict requires manual resolution
Verified against Git docs: git-merge — HOW CONFLICTS ARE PRESENTED, Pro Git book: Chapter 3.2 — Basic Merge Conflicts, Git source: merge-recursive.c conflict handling · Updated June 2026
> quick_fix
Two branches changed the same lines in the same file. Git inserted <<<<<<< / ======= / >>>>>>> markers showing both versions. Open the file, decide which version to keep (or combine both), remove the markers, then git add the file and git commit.
# See which files have conflicts
git status
# Open conflicted file, resolve the markers:
# <<<<<<< HEAD
# your version
# =======
# their version
# >>>>>>> branch-name
# After editing, mark resolved:
git add resolved-file.txt
git commitWhat causes this error
Git's three-way merge algorithm compares the common ancestor commit with both branch tips. When both branches modify the same lines in the same file, Git cannot automatically determine which change should win. Instead of guessing, it writes both versions into the file separated by conflict markers (<<<<<<< HEAD, =======, >>>>>>> branch-name) and pauses the merge, requiring you to manually resolve the conflict. This is a safety mechanism — Git refuses to lose work by silently picking one version over another.
How to fix it
- 01
step 1
Identify conflicted files
Run git status. Files with conflicts show as 'both modified' under 'Unmerged paths'. These are the files you need to edit.
git status # Unmerged paths: # both modified: src/app.ts - 02
step 2
Open the file and find conflict markers
Search for <<<<<<< in the file. Everything between <<<<<<< HEAD and ======= is your branch's version. Everything between ======= and >>>>>>> is the incoming branch's version. Decide which to keep, or combine both.
- 03
step 3
Remove all conflict markers
Delete the <<<<<<< HEAD, =======, and >>>>>>> lines. Leave only the final resolved code. Make sure no markers remain — a stray <<<<<<< in committed code is a common mistake.
# Quick check: no remaining markers grep -rn '<<<<<<< \|======= \|>>>>>>>' src/ - 04
step 4
Stage the resolved file and complete the merge
Run git add on each resolved file, then git commit (no -m needed — Git provides a default merge commit message).
git add src/app.ts git commit
How to verify the fix
- git status shows no 'Unmerged paths'.
- grep -rn '<<<<<<' finds no remaining conflict markers in the codebase.
- The application builds and tests pass after the merge commit.
Why CONFLICT happens at the runtime level
Git's merge algorithm (recursive strategy by default) works by finding the merge base — the most recent common ancestor of the two branches. It then computes two diffs: base→HEAD and base→MERGE_HEAD. When both diffs modify the same hunk (same line range in the same file), the algorithm cannot reconcile them automatically. The merge-recursive.c code detects this overlap, writes both versions with conflict markers into the working tree file, and records the file in the index at stages 1 (base), 2 (ours), and 3 (theirs). The merge halts with a non-zero exit code, leaving the repository in a 'MERGING' state until you resolve all conflicts and commit.
Common debug mistakes for CONFLICT
- Accepting all 'ours' or all 'theirs' without reading the actual changes — git checkout --ours . resolves fast but silently drops the incoming branch's work. Only use this when you genuinely want to discard all their changes.
- Leaving conflict markers in the committed code — a <<<<<<< or >>>>>>> that survives into the merge commit will break the application. Always grep for markers before committing.
- Resolving a conflict in an IDE's merge tool but not running tests afterward — the resolution may be syntactically valid but semantically wrong (e.g. both branches added different items to the same list and you kept only one).
- Panic-deleting the branch and re-creating it to avoid the conflict — the conflict will reappear next time you try to merge. The only way out is through: resolve the conflicting lines.
- Not pulling main before creating a feature branch — starting from a stale main guarantees more conflicts when you eventually merge back.
When CONFLICT signals a deeper problem
Frequent merge conflicts in the same files signal an architectural problem: too many concerns in one file. If four developers keep conflicting in routes.ts, the file is doing too much — it should be split so each developer's feature touches a different file. The same applies to large CSS files, monolithic config objects, and god-class modules. The goal isn't zero conflicts (that's impossible in active codebases), but reducing conflict frequency by decomposing files along ownership boundaries. A team that refactors their router into per-feature route files will see merge conflicts drop by 80%.
Editor's take
The merge conflict that costs the most time isn't the complex one — it's the trivial one in a file nobody expected to conflict. Package lockfiles (package-lock.json, yarn.lock) are the classic example: two developers independently add a dependency, both lockfiles diverge, and the 50,000-line conflict in package-lock.json is unresolvable by hand. The correct move is to accept one version (git checkout --theirs package-lock.json), run npm install to regenerate, and commit the result. But most developers try to manually merge the lockfile, waste 30 minutes, and end up with a corrupted lockfile that breaks npm install for the next person.
The skill gap between a junior and senior developer when resolving merge conflicts isn't technical ability — it's the judgment to know when a conflict needs careful reading (business logic, data migrations) versus when it's mechanical (lockfiles, auto-generated code, formatting changes). A senior developer resolves the first kind slowly and carefully, and the second kind in under 10 seconds with --ours/--theirs plus regeneration.
In the same merge session you'll often encounter: 'error: you need to resolve your current index first' if you try to checkout another branch mid-conflict, 'fatal: cannot do a partial commit during a merge' if you try to commit individual files while other conflicts remain, and CONFLICT (modify/delete) when one branch edited a file the other branch deleted.
By Bikram Nath · Curator · Updated June 2026
Frequently asked questions
Can I abort a merge instead of resolving conflicts?
Yes — git merge --abort reverts to the state before you started the merge. All conflicts and partial resolutions are discarded. Use this when you realize you merged the wrong branch or need to prepare before resolving.
How do I prevent merge conflicts?
You can't entirely prevent them — they're normal when multiple people edit the same code. But you can reduce them: merge main into your feature branch frequently, keep feature branches short-lived, avoid reformatting files you're not meaningfully changing, and coordinate with teammates on shared files.
What's the difference between merge conflicts and rebase conflicts?
Merge conflicts happen once (at merge time). Rebase conflicts can happen multiple times — once per commit being replayed. The resolution process is the same (edit markers, git add), but rebase uses git rebase --continue instead of git commit to proceed.