b2KIT

Git Conflict Resolver

Paste git merge conflict markers and resolve conflicts with a side-by-side visual editor.

Tested tool guide Tested browser tools Checked August 16, 2026

What Git Conflict Resolver does, with a checked example

Git Conflict Resolver turns the marker-delimited regions in a conflicted file into opposing editable views. Lines between <<<<<<< and ======= form one alternative, while lines between ======= and >>>>>>> form the other; surrounding text remains shared context. You use those views to compose a marker-free result. The common mistake is treating one side as automatically correct or newer. Git records competing content, but the editor cannot know which behavior the finished program should preserve.

Worked example

A concrete input and expected output from the current implementation.

Input

theme:
<<<<<<< HEAD
  color: blue
=======
  color: green
>>>>>>> feature/green

Expected output

theme:
  color: blue

This result keeps the HEAD alternative. The divider, boundary markers, feature label, and unselected green line are omitted from the resolved text.

How the result is produced

1

Reading a conflict block

An ordinary two-way conflict starts with <<<<<<< followed by a label. The first alternative continues until the ======= divider; the second continues until >>>>>>> and its label. The resolver presents those alternatives beside one another so line-level differences are visible. Text outside marked regions is non-conflicting context and belongs in the resolved file.

2

Building the resolution

Use the two panes as sources for the intended final text. A valid resolution can retain either alternative or reconcile lines from both, but it must remove the conflict-control lines themselves. Review every marked block independently. After obtaining the clean text, place it in the working-tree file, test it, and stage it with Git to record that the conflict was addressed.

Good uses

  • Choosing between conflicting values in a configuration file before staging the resolution.
  • Reconciling two branches that changed the same function in different ways.
  • Inspecting several marker blocks in a pasted source file without repeatedly scanning raw separators.

Limits and checks

  • A marker-free result is not proof that the code compiles, passes tests, or preserves the intended behavior.
  • Marker labels identify the competing content but do not establish that one alternative is newer or preferable.
  • Ordinary text markers do not represent every Git conflict, such as binary-file, file-mode, rename, or delete conflicts.

Common questions

Can the resolver determine which side is correct?

No. It can expose the alternatives and help assemble clean text, but correctness depends on the purpose of each change. Sometimes one side should replace the other; sometimes both changes are required in a newly edited form. Read the surrounding code, consult the related commits when necessary, and run the project's normal checks afterward.

Does resolving the pasted text finish the Git merge?

No. The tool works on the conflict text pasted into the browser and does not change the repository, update the index, or create a commit. Nothing is uploaded. Copy the resolved content into the affected working-tree file, confirm that no conflict markers remain unintentionally, stage the file with Git, and then continue the merge or rebase.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools