Resolving Merge Conflicts in GitKraken: What the Visual Tool Actually Does for You

You've run a merge, Git reports a conflict in three files, and now you're staring at a wall of <<<<<<< markers. The usual advice is "learn to read conflict markers," which is true but unhelpful at 4 PM on a Friday. GitKraken's built-in merge tool exists precisely for this moment — but it's worth understanding what it does under the hood so you know when to trust it and when to drop back to the terminal.

The problem with raw conflict markers

When Git can't auto-merge, it rewrites the file with both versions inlined between <<<<<<<, =======, and >>>>>>> markers. For a five-line conflict this is fine. For a 200-line refactor colliding with a hotfix, manual editing becomes error-prone: it's easy to delete a marker but keep both copies of a block, or accidentally discard the wrong side.

The underlying operation is a three-way merge. Git compares your branch ("ours"), the incoming branch ("theirs"), and the common ancestor ("base") to decide what changed where. GitKraken's merge tool is a graphical front end to that same logic — it doesn't change how Git merges anything.

What the merge tool shows you

When a merge or rebase produces conflicts in GitKraken, the conflicting files appear in the commit panel with a warning icon. Clicking one opens the merge tool with a side-by-side view of the two competing versions, and an editable output pane below.

The key features that reduce mistakes:

• Per-hunk checkboxes. Each conflicting block has a checkbox on the "ours" side and one on the "theirs" side. Checking a box inserts that block into the output. You can check both (both blocks are kept, in the order you select them) or neither.
• Non-conflicting changes are pre-merged. Just like git merge itself, hunks that only one side touched are applied automatically — you only decide on genuine collisions.
• Manual edits in the output pane. If neither side is exactly right, you can type directly into the result, combining a line from ours with a line from theirs.

When you save, GitKraken writes the resolved file and stages it in the Git index — the equivalent of running git add <file>. Once all conflicts are resolved, it prompts you to commit the merge. Nothing exotic happens here; if you inspected the repo with git status mid-resolution, you'd see the same "unmerged paths" state as any CLI merge.

A worked example

Say feature/pricing and main both edited a function in src/invoice.js. On main, someone added a currency-rounding line; on your branch, you renamed a variable across the function.

In GitKraken (this works the same on the current desktop client on Windows, macOS, or Linux; no special permissions needed beyond write access to the repo):

1. Drag main onto feature/pricing in the graph, or right-click main and choose Merge main into feature/pricing.
2. The conflict banner appears. Click src/invoice.js in the conflicted files list.
3. In the merge tool, the left pane shows your branch's version, the right shows main's. The rounding line appears as a hunk on the right; the variable rename appears on the left.
4. Because both changes are needed, check both boxes for the affected hunks, then fix any ordering issue directly in the output pane.
5. Click Save. The file is staged automatically. Resolve any remaining files, then commit the merge when prompted.

To verify the result independently, run this in a terminal at the repo root:

git diff HEAD~1 -- src/invoice.js
git log --oneline -3

The diff should show exactly the combined change you intended, and the log should show a merge commit with two parents. If the diff contains leftover conflict markers (search for <<<<<<<), the resolution didn't save cleanly — reopen the file.

Using the graph before you merge

An underrated part of the workflow is what happens before the conflict. GitKraken's commit graph makes it easy to see where the branches diverged and which commits touched the same file. If you can see that the collision comes from one specific commit on the other branch, you can sometimes rebase or cherry-pick in a different order to shrink the conflict, rather than resolving a giant one head-on. The visual context doesn't eliminate the conflict, but it tells you whether you're resolving a real semantic clash or just two people editing adjacent lines.

Trade-offs and limits

The GUI is a wrapper, not a smarter merge. A few honest limitations:

• Very large diffs can feel sluggish. A generated file with thousands of conflicting lines is often faster to handle in the terminal, or by taking one side wholesale with git checkout --theirs <file>.
• Binary files can't be merged visually. You still get an ours/theirs choice, which you could make without the tool.
• Skill atrophy is real. If GitKraken is the only way you've ever resolved a conflict, you'll be stuck on a server, in a CI job, or over SSH. It's worth doing a few resolutions with plain markers or git mergetool so the GUI stays a convenience, not a crutch.
• Rebase conflicts are per-commit. During an interactive rebase you may resolve the same conceptual conflict several times; the tool handles each one, but it won't warn you that you're repeating yourself.

Exact UI labels vary between GitKraken versions, so if a button name here doesn't match your client, check the current documentation — the underlying ours/theirs/output model has been stable for years.

The takeaway

Use the merge tool for what it's good at: turning a marker-filled file into a set of explicit, per-block decisions, and staging the result without extra commands. Verify the outcome with git diff before you push, and keep enough command-line fluency to survive without the GUI. The merge logic is Git's either way — GitKraken just makes the decisions visible.