doc/user/project/merge_requests/conflicts.md
{{< details >}}
{{< /details >}}
Merge conflicts occur when two branches in a merge request, the source and target, have different changes to the same lines of code. In most cases, GitLab can merge changes together, but when conflicts arise, you must decide which changes to keep.
To resolve a merge request with conflicts, you must either:
GitLab resolves conflicts by creating a merge commit in the source branch without merging it into the target branch. You can then review and test the merge commit to verify it contains no unintended changes and doesn't break your build.
When Git detects a conflict that requires a decision on your part, it marks the beginning and end of the conflict block with conflict markers:
<<<<<<< HEAD marks the beginning of the conflict block.======= marks the end of your changes.>>>>>>> marks the end of the conflict.To resolve a conflict, delete:
======= line between
the two versions.You can resolve merge conflicts in the GitLab UI if the conflicting file:
If a file doesn't meet these criteria, you must resolve the conflict manually.
GitLab shows conflicts available for resolution in the user interface, and you can also resolve conflicts using the following methods:
Interactive mode merges the target branch into the source branch with your chosen changes.
To resolve merge conflicts with interactive mode:
In the top bar, select Search or go to and find your project.
In the left sidebar, select Code > Merge requests and find the merge request.
Select Overview, and scroll to the merge request reports section.
Find the merge conflicts message, and select Resolve conflicts. GitLab shows a list of files with merge conflicts. The lines that conflict are highlighted.
For each conflict, select Use ours or Use theirs to mark the version of the conflicted lines you want to keep. This decision is known as "resolving the conflict."
When you've resolved all the conflicts, enter a Commit message.
Select Commit to source branch.
Some merge conflicts are more complex, and you must manually edit lines to resolve them.
The merge conflict resolution editor helps you resolve these conflicts in GitLab:
In the top bar, select Search or go to and find your project.
In the left sidebar, select Code > Merge requests and find the merge request.
Select Overview, and scroll to the merge request reports section.
Find the merge conflicts message, and select Resolve conflicts. GitLab shows a list of files with merge conflicts.
Find the file to edit manually, and scroll to the conflict block.
In the header for that file, select Edit inline to open the editor. In this example, the conflict block begins at line 1350 and ends at line 1356:
After you resolve the conflict, enter a Commit message.
Select Commit to source branch.
If your merge request is stuck with a Checking ability to merge automatically
message, you can:
/rebase quick action.To troubleshoot CI/CD pipeline issues, see debugging CI/CD pipelines.
For projects that use the semi-linear or fast-forward merge method, you can also turn on automatic rebase before merge to skip the manual rebase step.
To trigger a rebase from the GitLab UI, use the /rebase quick action, or the
rebase option in the merge request widget.
Prerequisites:
To rebase a merge request's branch from the GitLab UI:
/rebase and select Comment.GitLab schedules, then runs, a rebase of the branch against the default branch. GitLab shows the completed rebase as a system note.
[!note] If you have configured commit signing for commits made through the GitLab UI, web commits lose their commit signatures when rebased through the UI.