GitKraken's Built-In Merge Conflict Editor: What It Does and What to Verify

A conflict that costs more than it should

Two branches change the same function in src/utils.js. You merge, Git stops, and the file now contains marker fences like this:

<<<<<<< HEAD
function formatPrice(v) { return v.toFixed(2); }
=======
function formatPrice(v) { return v == null ? "—" : formatCurrency(v); }
>>>>>>> feature/price-nulls

Nothing here is hard, but the work is fiddly: read both sides, decide what the combined function should be, delete the markers, and don't drop a brace. GitKraken's built-in merge conflict editor targets exactly that step. It shows the base, current, and incoming versions side by side and gives you an editable output pane, so you resolve without leaving the app or hunting for marker fences.

The thesis is narrow: the editor removes the mechanical part of conflict resolution, not the judgment part. You still decide what the merged code should do.

What the three panes actually represent

Git stores three versions of a conflicted file in the index, and the editor's panes map onto them:

• Base — the common ancestor, before either branch changed the file (index stage 1).
• Current / ours — the branch you're merging into, usually main (stage 2).
• Incoming / theirs — the branch being merged in (stage 3).

The output pane is a plain text editor. That matters because the common case isn't "pick one side" — it's "both changes are wanted, in the right order." Clicking a hunk gets you close; typing in the output pane finishes the job.

Enabling it — and why you should check your own install

GitKraken has shipped a built-in merge tool for a long time, but the preference label and its location have moved between releases, and some configurations hand conflicts to an external merge tool instead. So don't trust a hard-coded menu path from any article, including this one. Instead:

1. Open Preferences and search for merge.
2. Find the merge-tool setting and confirm the built-in editor is selected rather than an external tool.
3. If you only see an external-tool option, your version predates the built-in editor — update, or keep using your external tool.

If your team standardizes on this, that check belongs in onboarding, not in a wiki page nobody updates.

A worked example: two edits to one function

Say main added currency formatting to formatPrice, and a feature branch added null handling. Both touch the same lines, so the merge conflicts. In GitKraken:

1. Start the merge from the branch context menu (some versions also let you drag one branch onto another). GitKraken flags the conflicted file.
2. Open the conflicted file; the three-pane editor appears.
3. Accept the incoming hunk for the currency logic and the current hunk for the null check.
4. In the output pane, reorder so the null check runs first — the combined function is neither side verbatim.
5. Use the editor's search to find any remaining hunks and mark each resolved.
6. Save or mark the file resolved, then create the merge commit through GitKraken's normal commit flow.

Two things the tool does not do for you. First, it does not create the merge commit — resolving updates the file and clears the conflict state, but the commit is a separate action. Second, it does not push. A resolved merge sitting only on your machine leaves the branch unmergeable for everyone else.

Checking that the resolution is actually correct

Run these in a terminal at the repository root. No special permissions are required; they only read state.

git status
git log --oneline -1
git diff --check

• git status should report no unmerged paths. If it still lists the file as "both modified," the resolution wasn't saved or staged.
• git log --oneline -1 should show a merge commit. Git generates that message itself; depending on your Git version and configuration it may read Merge branch 'feature' or include an into main suffix. Don't script against the exact wording.
• git diff --check catches leftover conflict markers and whitespace errors in the staged content.

Then open the file and confirm both changes survived, and run whatever tests cover that module. The editor guarantees a syntactically clean merge, not a semantically correct one.

Where the editor stops helping

It works on text. Binary assets — images, compiled artifacts, design files — have no lines to compare, so the editor can't merge them; you pick one side wholesale (for example git checkout --ours -- path/to/asset or --theirs) or regenerate the file. Very large text files are also a poor fit for any side-by-side view, though the practical threshold depends on your machine and version, so test with your own files rather than trusting a number from a blog post.

The second trade-off is conceptual: a GUI hides the commands underneath. If your team writes merge scripts or wants people to understand index stages and git mergetool, the click-to-resolve flow can become a black box. A workable norm is to use the editor for speed while expecting everyone to read git status during a conflicted merge.

Practice before you need it

Create a throwaway repository, make two branches that edit the same line of a text file, and merge one into the other. Resolve it in GitKraken, commit, and run the three checks above. Ten minutes in a sandbox is cheaper than learning the tool on a release branch at 6 p.m.