How do you resolve merge conflicts in GitLab? Four ways, step by step

A merge conflict means the source and target branches of a merge request changed the same lines, and GitLab won’t guess which version wins. Until it is resolved, the merge request can’t be merged. Here are the four ways to resolve one in GitLab in 2026, and what each does to your branch.

How to tell it’s a conflict

The merge request’s Overview shows a merge conflicts message in the merge request reports section, and the conflict check in the merge widget fails. If you wrote the merge request, or set it to auto-merge, GitLab also adds a to-do to your To-Do List.

Inside a conflicting file, Git marks each conflict block like this:

<<<<<<< HEAD
timeout: 30
=======
timeout: 60
>>>>>>> origin/main

One branch’s version sits between <<<<<<< and =======, the other’s between ======= and >>>>>>>. To resolve it by hand, keep the lines you want and delete the other version and all three marker lines.

1. In the browser: Use ours or Use theirs

The quickest way, when each conflict is a choice between two versions:

1. Open the merge request, select Overview and scroll to the merge request reports section.
2. Find the merge conflicts message and select Resolve conflicts. GitLab lists the files with conflicts and highlights the conflicting lines.
3. For each conflict, select Use ours to keep the merge request’s version, or Use theirs to keep the target branch’s.
4. Enter a Commit message and select Commit to source branch.

GitLab merges the target branch into the source branch with your choices, as a merge commit on the source branch. Nothing reaches the target branch yet, so you can review that commit and let your pipeline test it before you merge.

2. Edit inline when you need both versions

When the right answer combines both sides, go to Resolve conflicts the same way, find the file and select Edit inline in its header. Edit the conflict block into the version you want, enter a Commit message and select Commit to source branch.

When the browser can’t do it

GitLab only resolves a conflict in the browser if the file:

• is a non-binary text file,
• is under 200 KB with the conflict markers added,
• uses a UTF-8 compatible encoding,
• doesn’t already contain conflict markers, and
• exists under the same path in both branches, so a file moved on one branch and changed on the other has to be resolved locally.

The commit goes to the source branch, so you also need to be able to push to it. On a merge request from a fork, the author can select Allow commits from members who can merge to the target branch under Contribution. Members who can merge to the target branch can then write to the fork’s branch, to fix a conflict or rebase. The option is for forks that are publicly accessible.

3. Let GitLab Duo resolve it

On Premium and Ultimate, GitLab Duo can resolve conflicts on its own: it analyzes them, edits the files, commits and pushes to the source branch, then posts a summary comment on the merge request. It arrived in GitLab 19.0 and has been generally available since 19.3.

• Start it: in the reports section, select Resolve conflicts and then Resolve with GitLab Duo, or select Resolve with GitLab Duo on the conflict check row of the merge widget.
• What it needs: the Developer, Maintainer or Owner role, push access to the source branch, the GitLab Duo Agent Platform, and a conflict the browser could resolve, so the file limits above apply.
• What it won’t do: it follows branch protection rules and doesn’t force-push to protected branches.

Read its commit before you merge, as you would a teammate’s.

4. On the command line

For complex conflicts, or files the browser can’t take, resolve them locally. GitLab’s guide rebases the branch onto the target branch:

git switch my-feature-branch
git fetch
git rebase origin/main
# fix each conflicting file and delete the markers, then:
git add path/to/file
git rebase --continue
git push origin my-feature-branch --force-with-lease

Until the rebase finishes, git rebase --abort puts the branch back as it was. Two things to know:

• In a rebase, the sides swap. The HEAD side of a conflict is the target branch plus the commits replayed so far, and your commit is the other side.
• A rebase needs a force push, because it rewrites the branch’s history. --force-with-lease only overwrites the branch if nobody has pushed to it since you fetched. A protected branch refuses force pushes unless it is set to allow them.

If you would rather not force push, merge the target branch into yours, which is what GitLab’s Resolve conflicts does:

git switch my-feature-branch
git fetch
git merge origin/main
# fix each conflicting file and delete the markers, then:
git add path/to/file
git commit
git push

After you resolve: approvals and rebases

• Approvals may reset. On Premium and Ultimate, the default setting Remove all approvals when commits are added to the source branch treats the resolution commit like any other push, so reviewers approve again. More in can you approve your own GitLab merge request?
• A rebase makes you a committer. If the project prevents approvals by users who add commits, whoever rebased can’t approve, and an approval they gave before the rebase can still show without counting.
• A rebase alone is one click. The fast-forward and semi-linear merge methods ask for a rebase whenever the target branch moves. With no conflicts, select Rebase source branch in the merge widget or comment /rebase; it needs at least the Developer role on the source project. If GitLab replies that the merge request “is currently in an unmergeable state, and cannot be rebased”, resolve any conflicts first, then check that both branches exist and the source branch has commits. Projects on those merge methods can also turn on automatic rebase before merge.
• Stuck on “Checking ability to merge automatically”? GitLab’s docs suggest a rebase: /rebase, Rebase source branch, or Git.

Conflicts on your phone

A conflict lands on your To-Do List when the merge request is yours or you set it to auto-merge. MergeBell sends a push for each new to-do, free and checked every five minutes, and its merge sheet lists conflicts with approvals, unresolved threads and the pipeline, so you know why the merge won’t go before you tap. The fix itself happens in GitLab’s conflict editor or your terminal. If everything is green and it still won’t merge, see why can’t I merge my GitLab merge request?