Resolve Merge Conflicts in GitKraken with the Visual Conflict Editor

Desired Outcome

Use GitKraken’s built‑in merge‑conflict editor to resolve all conflicts, produce a clean commit without the usual <<<<<<<<<<< markers, and keep the commit history tidy.

Prerequisites

• GitKraken Desktop (not the web version) installed on your machine.
• Local Git repository with a branch that has pending merge or rebase conflicts.
• Branch checked out and ready for editing.
• GitKraken license that supports full merge‑conflict handling (required for older versions; newer releases include it in the free tier).

Procedure

1. Trigger the conflict – run the merge or rebase that produces conflicts. Example:

   git checkout feature-branch
   git merge develop   # or: git rebase develop
   

2. Open GitKraken – the conflicted files will appear as red nodes in the commit graph.
3. Launch the conflict editor – double‑click a red node or click the Open Conflict Editor button. The editor shows three tabs:
   • Left – your branch’s changes.
   • Right – the incoming branch’s changes.
   • Combined – the merged view where you can edit.
4. Resolve the conflict – either click the “Accept Left”, “Accept Right”, or “Accept Both” buttons next to each conflicting block, or manually edit the Combined view. You can copy/paste code, delete unwanted lines, or reformat as needed.
5. Mark as resolved – once all blocks are handled, click the Mark as Resolved button. GitKraken will stage the file.
6. Commit the resolution – add a meaningful message, e.g. Resolve merge conflict in utils.js, and commit. The commit will appear as a merge commit if you were merging, or a regular commit if you were rebasing.
7. Push the branch (optional) – if you need to share the resolved state, run git push origin feature-branch from the terminal or use GitKraken’s push button.

Expected Checks

• Run git status – it should show nothing to commit, working tree clean.
• Open the file in GitKraken’s editor – confirm no <<<<<<<<<<< or >>>>>>>>>>> markers remain.
• View the commit graph – the merge commit should appear with a single arrow from the merged branch to your current branch.
• Run git log --graph --oneline – the merge commit should be visible and the file contents should match what you see in the editor.
• Optionally run git diff --check to ensure no stray conflict markers are left in the working tree.

Recovery Options

• Unresolved markers remain – if you see conflict markers after committing, you can manually edit the file to remove them and then stage again:

  git add path/to/file
  git commit --amend -m "Clean up stray markers"
  

• Abort the merge/rebase – if you realize the conflict resolution was wrong before committing, run:

  git merge --abort   # or git rebase --abort
  

  This will return the repository to its pre‑conflict state.
• Reset to a clean state – if you accidentally committed a bad resolution, you can reset the branch to the previous commit:

  git reset --hard HEAD~1
  

  Use this with caution; it discards local changes.

Limitations & Caveats

• The conflict editor does not support submodule diffs or large binary files; those must be resolved manually via the terminal.
• Older GitKraken Desktop releases may require a paid license to use merge‑conflict support; newer versions include it in the free tier.
• When rebasing, GitKraken shows the same conflict editor, but the commit will be a regular commit rather than a merge commit.
• Always verify the resolved file in both the editor and via git diff before pushing to a shared repository.

Practical Example

Assume feature-branch diverged from develop and both changed app/main.py in the same line. After running git merge develop, GitKraken shows the file as red. The conflict editor reveals:

Left	Right	Combined
print("Feature branch version")	print("Develop version")

Choose Accept Left, click Mark as Resolved, commit with Resolve main.py conflict, and push. After git log --graph --oneline, you’ll see a merge commit pointing to both branches.