Paste a file with conflict markers, choose ours, theirs, both, base or your own edit for each conflict, and copy the resolved file.
To resolve a Git merge conflict online, paste the file with its conflict markers, choose Ours, Theirs, Both, Base or Edit for each conflict block, and copy the resolved file from the result box. Git writes a conflict as three parts. A line starting with <<<<<<< opens it and may carry a label such as HEAD. The lines under it are ours: the side of the branch you are on. A line of ======= separates the sides. The lines under that are theirs, the incoming change, and a line starting with >>>>>>> and a label closes the block. With the diff3 conflict style, a line starting with ||||||| and a label sits between ours and the separator, followed by the base: the text as it was before either side changed it. This page shows Base only when the block has that section. During a rebase Git swaps the two sides, so ours is the branch you are rebasing onto and theirs is your own commits. A marker counts only when it is at the very start of a line and is exactly seven characters long. A line with eight, an indented line, and a marker-looking string inside code are left alone.
The sample file has two conflicts. The first changes one line, the port. Choosing Theirs replaces its five marker lines with const PORT = Number(process.env.PORT) || 8080; and nothing else. The second is a diff3 block: ours is app.listen(PORT, () => console.log('up on ' + PORT)); the base is app.listen(3000); and theirs is a three-line app.listen call with a template string. Choosing Both (ours, then theirs) keeps ours first and theirs right after it, four lines in all, with no markers. After those two choices the counter reads 2 of 2 conflicts resolved and the result has no marker lines. Choose only the first and it reads 1 of 2 conflicts resolved, the second block stays exactly as you pasted it, markers and base included, and a notice says that 1 conflict is still unresolved. Edit opens a box that starts with the current choice, so you can mix lines from both sides and add your own.
Text outside the conflicts comes back character for character, because the file is cut into pieces and joined again instead of being rewritten. The one exception is a byte-order mark at the very start of a file you load with Load file, which is dropped; pasted text keeps it. Every line keeps its own ending, so a file with Windows line breaks (CRLF) leaves with CRLF, and text typed in the Edit box is written with the file's line ending. A block you do not resolve keeps all its marker lines and labels in the result. The labels, such as HEAD or feature/login, are used only to name the panes on screen. Both puts the two sides back to back and does not remove lines they share, so a line that appears on both sides will appear twice. It is a choice to make on purpose, for example for two imports that both belong.
A block that starts with <<<<<<< but never reaches ======= or >>>>>>> is not a conflict this page can resolve. It is reported by line number, for example Line 12, and left in the result as plain text, so the other conflicts still work. A >>>>>>> or ||||||| line with nothing to match is reported the same way. A lone ======= line is not reported, because Markdown uses it under headings. The page reads up to 1,000,000 characters and up to 300 conflicts at a time. It does not understand code: it cannot tell whether the merged result compiles or whether Both duplicated a function. Read the result, save it over the file, run your tests and then run git add on it. It does not run Git, so it cannot stage the file or finish the merge for you.
Paste the file that has the <<<<<<< ======= >>>>>>> lines into the box. Each conflict becomes a block with its sides next to each other, and you pick Ours, Theirs, Both or Edit for it. The counter shows progress such as 3 of 5 conflicts resolved. Copy the result, save it over the file in your repository, then run git add and commit.
In a merge, ours is the branch you have checked out, the HEAD side above the =======, and theirs is the branch you are merging in, below it. In a rebase it is the other way round: ours is the branch you rebase onto and theirs is your commits being replayed. The labels after <<<<<<< and >>>>>>> show the names, and the page prints them above each pane.
It is the base: the text as it was in the common ancestor before either branch changed it. Git writes it when merge.conflictStyle is set to diff3, for example with git config merge.conflictStyle diff3. When a block has it, a Base button appears next to Ours and Theirs. Keeping the base throws both changes away.
Its markers do not form a full set. Examples are a <<<<<<< on line 12 with no ======= before the next marker, or a >>>>>>> with no opening line. The page names the line and leaves those lines unchanged, so you can fix the markers in the box. Markers also need exactly seven characters in the first column; ======== with eight is ordinary text.
Yes. Each line keeps its own ending, so a CRLF file stays CRLF and a mixed file stays mixed. Text you type in the Edit box takes the line ending of the file, CRLF if the conflict block uses it. A block you leave unresolved is copied back unchanged, including the line endings of its marker lines.
No. The text is processed in your browser and is not uploaded. The file, your choices and the text you edit stay in this tab and are not saved: the page has no stored settings, and closing it clears them. Analytics count that the tool was used, never the text, the labels or the file name.