Pirate Praveen 54117d12b7 New upstream version 15.5.4+ds1

2022-11-25 23:54:43 +05:30

6.9 KiB

Raw Blame History

stage	group	info	type
Create	Code Review	To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments	reference, concepts

Merge conflicts (FREE)

Merge conflicts happen when the two branches in a merge request (the source and target) each have different changes, and you must decide which change to accept. In a merge request, Git compares the two versions of the files line by line. In most cases, GitLab can merge changes together. However, if two branches both change the same lines, GitLab blocks the merge, and you must choose which change you want to keep.

A merge request cannot merge until you either:

Create a merge commit.
Resolve the conflict through a rebase.

Conflicts you can resolve in the user interface

If your merge conflict meets all of the following conditions, you can resolve the merge conflict in the GitLab user interface:

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 less than 200 KB in size.
The file exists under the same path in both branches.

If any file in your merge request contains conflicts, but can't meet all of these criteria, you must resolve the conflict manually.

Conflicts GitLab can't detect

GitLab does not detect conflicts when both branches rename a file to different names. For example, these changes don't create a conflict:

On branch a, doing git mv example.txt example1.txt
On branch b, doing git mv example1.txt example3.txt.

When these branches merge, both example1.txt and example3.txt are present.

Methods of resolving conflicts

GitLab shows conflicts available for resolution in the user interface, and you can also resolve conflicts locally through the command line:

Interactive mode: UI method best for conflicts that only require you to select which version of a line to keep, without edits.
Inline editor: UI method best for more complex conflicts that require you to edit lines and manually blend changes together.
Command line: provides complete control over the most complex conflicts.

Resolve conflicts in interactive mode

To resolve less-complex conflicts from the GitLab user interface:

Go to your 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 conflicts 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."
Enter a Commit message.
Select Commit to source branch.

Resolving conflicts merges the target branch of the merge request into the source branch, using the version of the text you chose. If the source branch is feature and the target branch is main, these actions are similar to running git checkout feature; git merge main locally.

Resolve conflicts in the inline editor

Some merge conflicts are more complex, requiring you to manually modify lines to resolve their conflicts. Use the merge conflict resolution editor to resolve complex conflicts in the GitLab interface:

Go to your 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.
Select Edit inline to open the editor:
After you resolve the conflict, enter a Commit message.
Select Commit to source branch.

Resolve conflicts from the command line

While most conflicts can be resolved through the GitLab user interface, some are too complex. Complex conflicts are best fixed locally, from the command line, to give you the most control over each change:

Open the terminal and check out your feature branch. For example, my-feature-branch:
```
git checkout my-feature-branch
```
Rebase your branch against the target branch (here, main) so Git prompts you with the conflicts:
```
git fetch
git rebase origin/main
```
Open the conflicting file in your preferred code editor.
Find the conflict block:
- It begins with the marker: <<<<<<< HEAD.
- Next, it displays your changes.
- The marker ======= indicates the end of your changes.
- Next, it displays the latest changes in the target branch.
- The marker >>>>>>> indicates the end of the conflict.
Edit the file:
1. Choose which version (before or after =======) you want to keep.
2. Delete the version you don't want to keep.
3. Delete the conflict markers.
Save the file.
Repeat the process for each file that contains conflicts.
Stage your changes in Git:
```
git add .
```
Commit your changes:
```
git commit -m "Fix merge conflicts"
```
Continue the rebase:
```
git rebase --continue
```
WARNING: Up to this point, you can run git rebase --abort to stop the process. Git aborts the rebase and rolls back the branch to the state you had before running git rebase. After you run git rebase --continue, you cannot abort the rebase.
Force-push the changes to your remote branch.

Merge commit strategy

GitLab resolves conflicts by creating a merge commit in the source branch, but does not merge it into the target branch. You can then review and test the merge commit. Verify it contains no unintended changes and doesn't break your build.

Introduction to Git rebase and force-push.
Git GUI apps to help you visualize the differences between branches and resolve them.

6.9 KiB Raw Blame History