DiffKit / Merge conflict resolver
Git merge conflict resolver
Paste a file that git left with <<<<<<< markers. Each conflict is shown side by side, and you pick current, incoming or both, write your own merge, or ask AI for a suggestion. Then take away a clean file.
Anatomy of a conflict
<<<<<<< HEAD
const PORT = process.env.PORT || 3000 ← current (your branch)
||||||| base
const PORT = 3000 ← common ancestor (diff3 only)
=======
const PORT = Number(process.env.PORT) || 8080 ← incoming (being merged)
>>>>>>> feature/security-headersGit writes these markers when both branches changed the same lines, or neighbouring lines, since their common ancestor, so it can’t know which edit should win. Everything outside the markers has already been merged for you. This tool reads the markers, splits the file into clean text and conflict blocks, and rebuilds the file from your choices, leaving markers in place only for blocks you haven’t resolved.
Picking the right option
| Choose | When |
|---|---|
| Accept current | The incoming change is outdated or already covered on your branch. |
| Accept incoming | Their version supersedes yours, for example a renamed function or a newer dependency version. |
| Both | The two sides added independent lines, such as two imports or two routes. Pick the order. |
| Edit by hand | Both edited the same line with different intent, like the port example above. Combine them yourself. |
| AI suggestion | You want a first draft of a combined version to review, especially for longer blocks. |
Want to understand why git produces conflicts at all? The guide to resolving merge conflicts includes an interactive three-way merge you can play with.
Questions people ask
How do I use this with a real git conflict?
When git merge, rebase, cherry-pick or stash pop stops with “CONFLICT (content)”, open the listed file in any editor, copy everything and paste it here. Choose a side for each block, copy or download the resolved file, overwrite the original, then run git add <file> and git commit (or git rebase --continue).
What is “current” and what is “incoming”?
Current is the section between <<<<<<< and =======, which is HEAD, the branch you are on. Incoming is the section between ======= and >>>>>>>, the branch or commit being merged in. During a rebase they swap meaning: HEAD is the branch you are rebasing onto, and incoming is your own commit being replayed.
What is the “common ancestor” block?
If git is configured with merge.conflictStyle diff3 (or zdiff3), each conflict also shows the original text from the merge base between ||||||| and =======. Seeing the base tells you what each side actually changed, which makes the right resolution much clearer. Enable it with: git config --global merge.conflictStyle zdiff3
Is the AI suggestion safe to accept?
Treat it like a review comment. The model sees only the conflicting block plus up to 12 lines on either side, not your whole project, so it can’t know about code elsewhere. Read the merged lines, edit them if needed, and run your tests before committing.
Does my code get uploaded?
Parsing and resolving happen in your browser. Code is sent only when you click “Suggest a merge with AI”, and then only that one conflict and its nearby context. Nothing is stored on our side.
Can it resolve binary or lock-file conflicts?
Binary files have no text markers, so no. For package-lock.json, yarn.lock or pnpm-lock.yaml, it is usually safer to accept either side and then re-run npm install, yarn or pnpm install so the lock file is regenerated.