Using GitKraken’s Built-In Merge Conflict Editor for Pull Requests

The problem: a conflict blocks the pull request

A teammate opens a pull request against your main branch, and the remote reports a merge conflict. The conflicting file is a large refactor with changes across several functions. You could drop to the terminal, run git merge, edit conflict markers by hand, and hope you do not accidentally delete a block of logic. For complex files, that manual process is error-prone, especially when the team includes engineers who are less comfortable with rebase mechanics.

GitKraken includes a built-in merge conflict editor that displays conflicting hunks side by side and lets you accept the incoming change, the current change, or a combination of both. The practical question for a team is not whether the tool exists, but when it is the right choice and what it hides from view.

How the editor fits a pull-request workflow

When a repository has an active merge conflict, GitKraken can open the affected file in its visual editor instead of requiring an external diff tool. Each conflicting section appears as a hunk with labels for the two branches involved. You select which version to keep, or edit the combined result directly. Once the file is clean, GitKraken stages it and lets you commit from the same interface. Behavior may vary by GitKraken version, so confirm the conflict editor appears for your installed release.

This works with pull requests from GitHub, GitLab, and Bitbucket when you are using GitKraken’s integrated pull-request management. The GUI does not bypass repository permissions: after you commit the resolution, you still push to the remote, and the remote’s branch-protection rules still apply.

Worked example: resolving a conflict in a shared configuration file

Suppose two branches modified deploy.yml. One branch changed the replica count, and the other changed the image tag. The pull request is flagged as unmergeable.

1. Open the repository in GitKraken and fetch the latest remote state.
2. Start the merge or rebase operation for the pull-request branch. GitKraken typically detects the conflict and lists deploy.yml as unresolved.
3. Open deploy.yml in GitKraken’s conflict editor. You will see two panels: the current branch version and the incoming branch version.
4. For the replica-count hunk, choose the incoming change. For the image-tag hunk, choose the current branch version. If both changes are valid, edit the combined result manually.
5. Save the file. GitKraken marks it as resolved and stages it.
6. Commit the resolution from the GitKraken commit panel, then push to the remote.

Run this check in your terminal after the push:

# Run in the repository working directory
git status
git log --oneline -3

Expected result: git status reports a clean tree with nothing to commit, and git log shows a new merge or commit on your branch. If the tree is still dirty, a conflict file was not saved or staged correctly.

Permissions and risk: these commands require read access to the local repository and write access to push to the remote. Pushing a rewritten history on a shared branch can overwrite other teammates’ work; avoid force-pushing after a conflict resolution unless the team has agreed to it.

Trade-off: visual convenience versus visible history

The editor reduces the chance of deleting a hunk by mistake, but it can also obscure the exact parent-commit lineage during an interactive rebase. An engineer who resolves everything through the GUI may not learn how Git records which commit introduced which change. For teams that rely on strict rebase-based histories, that opacity is a real cost.

GitKraken’s free tier may also limit advanced collaboration features. Before rolling this out, check the current feature comparison page to confirm that merge-conflict editing and pull-request integration are included in your plan.

Practical verification and closing

Before adopting the editor as a team standard, try it on a low-stakes branch:

• Create a test branch and introduce a deliberate conflict in a non-production file.
• Resolve it in GitKraken, commit, and push.
• Run git status and git log locally to confirm the commit was created normally.
• Confirm the pull request on the remote shows the branch as mergeable.

If the result is a clean tree and a normal commit, the GUI path is safe for your workflow. Use it for complex refactors where manual conflict markers are risky, but keep the terminal available for rebases and history audits.