2019-09-04 21:01:54 +05:30
---
2020-10-24 23:57:45 +05:30
stage: Create
2021-04-17 20:07:23 +05:30
group: Code Review
2021-02-22 17:27:13 +05:30
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2019-09-04 21:01:54 +05:30
type: reference, concepts
---
2021-03-11 19:13:27 +05:30
# Merge request conflict resolution **(FREE)**
2016-09-13 17:45:13 +05:30
2019-02-15 15:39:39 +05:30
Merge conflicts occur when two branches have different changes that cannot be
merged automatically.
2016-09-13 17:45:13 +05:30
2021-03-11 19:13:27 +05:30
Git can merge changes between branches in most cases, but
occasionally Git requires your assistance to resolve the
2019-02-15 15:39:39 +05:30
conflicts manually. Typically, this is necessary when people change the same
parts of the same files.
2021-03-11 19:13:27 +05:30
GitLab prevents merge requests from being merged until all conflicts are
resolved. Conflicts can be resolved locally, or in many cases in GitLab
2019-02-15 15:39:39 +05:30
(see [conflicts available for resolution ](#conflicts-available-for-resolution )
for information on when this is available).
2016-09-13 17:45:13 +05:30
![Merge request widget ](img/merge_request_widget.png )
2021-02-22 17:27:13 +05:30
NOTE:
2019-02-15 15:39:39 +05:30
GitLab resolves conflicts by creating a merge commit in the source branch that
2021-03-11 19:13:27 +05:30
is not automatically merged into the target branch. The merge
commit can be reviewed and tested before the changes are merged. This prevents
2019-02-15 15:39:39 +05:30
unintended changes entering the target branch without review or breaking the
build.
## Resolve conflicts: interactive mode
2021-03-11 19:13:27 +05:30
Clicking **Resolve Conflicts** displays a list of files with conflicts, with conflict sections
2016-09-13 17:45:13 +05:30
highlighted:
![Conflict section ](img/conflict_section.png )
2021-03-11 19:13:27 +05:30
After all conflicts have been marked as using 'ours' or 'theirs', the conflict
can be resolved. Resolving conflicts merges the target branch of the merge
request into the source branch, using the options
2021-09-04 01:27:46 +05:30
chosen. If the source branch is `feature` and the target branch is `main` ,
this is similar to performing `git checkout feature; git merge main` locally.
2016-09-13 17:45:13 +05:30
2019-02-15 15:39:39 +05:30
## Resolve conflicts: inline editor
2017-08-17 22:00:37 +05:30
2021-03-11 19:13:27 +05:30
Some merge conflicts are more complex, requiring you to manually modify a file to
resolve them. Use the merge conflict resolution editor to resolve complex
conflicts in the GitLab interface. Click **Edit inline** to open the editor.
After you're sure about your changes, click **Commit to source branch** .
2017-08-17 22:00:37 +05:30
![Merge conflict editor ](img/merge_conflict_editor.png )
2016-09-13 17:45:13 +05:30
## Conflicts available for resolution
GitLab allows resolving conflicts in a file where all of the below are true:
- The file is text, not binary
- The file is in a UTF-8 compatible encoding
- The file does not already contain conflict markers
- The file, with conflict markers added, is not over 200 KB in size
- The file exists under the same path in both branches
2021-03-11 19:13:27 +05:30
If any file in your merge request containing conflicts can't meet all of these
criteria, you can't resolve the merge conflict in the UI.
2016-09-13 17:45:13 +05:30
Additionally, GitLab does not detect conflicts in renames away from a path. For
2021-03-11 19:13:27 +05:30
example, this does not create a conflict:
1. On branch `a` , doing `git mv file1 file2`
1. On branch `b` , doing `git mv file1 file3` .
Instead, both files are present in the branch after the merge request is merged.
2019-09-04 21:01:54 +05:30
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X` .
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->