Merge Conflict Marker Cleaner
Resolve <<<<<<< / ======= / >>>>>>> blocks by choosing ours, theirs, both or the base — per conflict.
What is Conflict Cleaner?
A merge conflict resolver that works on pasted text. It shows each conflicting block with both sides, lets you choose per block, and everything outside the markers is copied through untouched.
How it works
The text is scanned line by line. Between `<<<<<<<` and `>>>>>>>` the content is split into ours, base (if the block is diff3-style with `|||||||`) and theirs. The strategy you pick is applied to every block, individual blocks can override it, and the output is reassembled. Orphan markers, unterminated blocks, empty sides and leftover markers after resolution are all reported.
- Paste or fill in the input. Drop in a commit message, a diff, a package.json, a path list or a set of options. The tool reads it locally — nothing is uploaded and no repository is contacted.
- Adjust the rules to match your project. Every linter here takes its convention from a setting you can change: allowed commit types, header length, target branch length, known branch names. Set them once to what your team actually uses.
- Copy the result. Generated files copy straight to the clipboard or download as a real file with the right name (.gitignore, CODEOWNERS, LICENSE, COMMIT_EDITMSG), and Reset returns every field to its default.
Examples
A commit message that fails CI
"Updated(auth): Fixed the expired-token redirect." is rejected by release automation and reported here with the exact reasons: unknown type, capitalised description, past tense and a trailing period.
A .gitignore that only half works
The Checker shows which rule decides a path — and why `!keep.txt` inside an ignored directory never fires, the mistake that sends people to Stack Overflow.
A dependency bump nobody reviewed
The package.json Diff separates added, removed and changed entries per section, so a caret bump of a runtime dependency does not hide inside a lockfile-sized pull request.
A diff pasted from a code review comment
The Diff Viewer understands several `diff --git` blocks, mode-only changes, renames and binary stubs, and calls out a pasted `--stat` summary instead of rendering an empty box.
Common mistakes
Committing a .gitignore without checking it
Rules look right and behave differently: a pattern containing a slash is anchored to the root, a trailing slash means directories only, and a file inside an ignored directory cannot be re-included. Check the paths that matter before you commit the file.
Rewriting published history
A clean commit history is worth having, but amend, rebase and filter-repo change commit hashes. Only rewrite commits that nobody has pulled; after a rewrite, push with --force-with-lease rather than --force.
Treating a generated file as if it were reviewed
These tools produce a starting point, not a decision. Check the licence text against the canonical source, read the security policy before publishing it, and make sure a CODEOWNERS team actually exists — GitHub silently ignores rules whose owner has no write access.
Putting slow checks in a pre-commit hook
A hook that takes 30 seconds gets bypassed with --no-verify within a week, and then it protects nothing. Keep pre-commit to formatting and linting, move type checks and tests to pre-push or CI.
Frequently asked questions
What is the third section in a diff3 conflict?
The common ancestor's version of the lines, written between `|||||||` and `=======`. It is often the most useful part, because it shows what each side actually changed relative to the same starting point.
Which side is "ours"?
The branch you are on when the merge starts — HEAD. "Theirs" is the branch being merged in, and during a rebase the meaning swaps, which is why the labels are printed next to each block.
Is resolving a conflict the same as merging it?
No. Resolving produces the file; you still have to git add it and finish the merge. Run the tests afterwards — a conflict that resolves cleanly can still be wrong, and `git diff --check` only proves no markers were left.