Choosing a Merge Conflict Resolution Method in GitKraken: Built‑in vs External Tools

The decision you face

When a merge conflict appears in GitKraken you must decide how to resolve it: use the built‑in three‑pane editor that ships with the client, or hand the conflict off to an external merge tool such as VS Code, Beyond Compare, or Kaleidoscope. The choice affects team consistency, licensing cost, and the amount of context switching each developer performs.

Constraints that shape the choice

• Team familiarity – If most developers already use VS Code daily, an external tool feels natural; otherwise the built‑in editor requires zero onboarding.
• License budget – Proprietary tools (Beyond Compare, Kaleidoscope) need per‑seat licenses; the built‑in editor is free with any GitKraken tier.
• Cross‑platform parity – The built‑in UI behaves identically on Windows, macOS, and Linux. External tools must be installed and configured on every machine.
• GitKraken version – The current three‑pane UI and merge‑tool preferences require GitKraken ≥ 8.x (9.x adds improved conflict markers).

Quick comparison

Aspect	Built‑in editor	External tool
Setup	None – opens automatically from the Commit panel	Preferences → Merge Tool → Custom command template
Interface	Three panes (base, local, remote) with inline actions, syntax highlighting, auto‑merge suggestions, keyboard shortcuts	Full IDE environment – refactoring, plugins, custom scripts
Context switching	None – stays inside GitKraken	Opens separate window; may disrupt flow
Licensing	Free with GitKraken	May require paid licenses (e.g., Beyond Compare)
Directory merges	Not supported	Supported if the external tool handles folder diffs
Configuration drift	Impossible – single source of truth	Each machine must replicate the same command template and tool version

Trade‑offs in practice

The built‑in editor eliminates context switching and guarantees every contributor sees the same conflict UI. It is ideal for teams that want a lightweight, zero‑config workflow and for repositories where conflicts are mostly line‑level. External tools shine when you need advanced refactoring, language‑aware navigation, or when a conflict spans multiple files and a directory merge is required. The downside is the extra configuration step on each workstation and the risk of version mismatches between team members.

Using the built‑in editor (no configuration needed)

1. Open the repository in GitKraken.
2. In the Commit panel, locate the conflicted file (marked with a red warning icon).
3. Click the file – the three‑pane editor launches automatically.
4. Resolve conflicts by choosing Local, Remote, or editing the merged pane directly.
5. Stage the resolved file and commit.

Because the editor is bundled, there are no permissions or PATH concerns. It works the same on all supported OSes.

Configuring an external merge tool – VS Code example

Below is a concrete, reproducible setup for Visual Studio Code (version 1.85+). Run the steps on each developer machine.

1. Ensure code is on the system PATH (VS Code → Shell Command: Install 'code' command in PATH).
2. In GitKraken, open Preferences → Merge Tool.
3. Select Custom.
4. Paste the following command template into the Command field:

   code --wait $LOCAL $REMOTE $BASE $MERGED

   GitKraken substitutes the four variables at runtime:

   • $LOCAL – your branch’s version
   • $REMOTE – the incoming branch’s version
   • $BASE – common ancestor
   • $MERGED – file GitKraken expects you to write the final result to
5. Leave Arguments empty; the template already contains them.
6. Click Save.

Permissions: No elevated rights required; the command runs under your user session. Risk: An incorrect template (missing $MERGED or wrong ordering) causes GitKraken to wait indefinitely or to accept a file still containing conflict markers.

Validation steps – confirm the resolution works

1. Create a temporary repository: git init test-merge && cd test-merge.
2. Add a file, commit on main, create a branch feature, edit the same lines differently on both branches, then merge feature into main to generate a conflict.
3. Resolve the conflict using the method you configured (built‑in or VS Code).
4. After staging and committing, run:

   git diff --check

   This command exits with status 0 only if no conflict markers (<<<<<<<, >>>>>>>) remain.

5. Execute the project’s test suite (e.g., npm test, pytest, go test ./...) to ensure the merge didn’t break logic.
6. In GitKraken, open the commit graph – the resolved file should appear clean, with no warning icon.

If any step fails, revisit the merge tool command template or re‑resolve the conflict.

Limitations and gotchas

• Directory conflicts – GitKraken’s built‑in editor cannot merge folder‑level conflicts; you must use an external tool or the CLI.
• Linux PATH – On Linux, GitKraken may not inherit your shell’s PATH. Verify the external tool’s binary is in a directory listed in /etc/environment or launch GitKraken from a terminal that has the correct PATH.
• License gating – Some advanced merge features (e.g., conflict‑resolution history) are only available on GitKraken Pro/Enterprise. The free tier still supports the built‑in editor and custom external tools.
• Silent failures – An external tool that exits with code 0 but leaves conflict markers will be accepted by GitKraken. Always run git diff --check after a merge.

Practical checklist for the team

• Agree on a single resolution method per project (or per repo) and document it in CONTRIBUTING.md.
• If using an external tool, store the exact command template in the repo (e.g., .gitkraken/merge-tool.txt) so new contributors can copy‑paste.
• Run the validation script above as part of your CI pipeline for any merge commit that had conflicts.
• Periodically review GitKraken release notes (≥ 9.x) for changes to merge‑tool variable handling.

By aligning on a single, validated workflow you eliminate the “works on my machine” friction that often appears when merge conflicts land in a shared codebase.