debian-mirror-gitlab/doc/user/project/merge_requests/index.md

stage	group	info	type
Create	Source Code	To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers	index, reference

Merge requests

A Merge Request (MR) is a request to merge one branch into another.

Use merge requests to visualize and collaborate on proposed changes to source code.

Use cases

A. Consider you're a software developer working in a team:

1. You checkout a new branch, and submit your changes through a merge request
2. You gather feedback from your team
3. You work on the implementation optimizing code with Code Quality reports
4. You verify your changes with Unit test reports in GitLab CI/CD
5. You avoid using dependencies whose license is not compatible with your project with License Compliance reports (ULTIMATE)
6. You request the approval from your manager (STARTER)
7. Your manager:
   1. Pushes a commit with their final review
   2. Approves the merge request (STARTER)
   3. Sets it to merge when pipeline succeeds
8. Your changes get deployed to production with manual actions for GitLab CI/CD
9. Your implementations were successfully shipped to your customer

B. Consider you're a web developer writing a webpage for your company's website:

1. You checkout a new branch, and submit a new page through a merge request
2. You gather feedback from your reviewers
3. Your changes are previewed with Review Apps
4. You request your web designers for their implementation
5. You request the approval from your manager (STARTER)
6. Once approved, your merge request is squashed and merged, and deployed to staging with GitLab Pages
7. Your production team cherry picks the merge commit into production

Overview

Merge requests (aka "MRs") display a great deal of information about the changes proposed. The body of an MR contains its description, along with its widget (displaying information about CI/CD pipelines, when present), followed by the discussion threads of the people collaborating with that MR.

MRs also contain navigation tabs from which you can see the discussion happening on the thread, the list of commits, the list of pipelines and jobs, the code changes, and inline code reviews.

To get started, read the introduction to merge requests.

Merge request navigation tabs at the top

Introduced in GitLab 12.6. This positioning is experimental.

So far, the navigation tabs present in merge requests to display Discussion, Commits, Pipelines, and Changes were located after the merge request widget.

To facilitate this navigation without having to scroll up and down through the page to find these tabs, based on user feedback, we're experimenting with a new positioning of these tabs. They are now located at the top of the merge request, with a new Overview tab, containing the description of the merge request followed by the widget. Next to Overview, you can find Pipelines, Commits, and Changes.

Please note this change is currently behind a feature flag which is enabled by default. For self-managed instances, it can be disabled through the Rails console by a GitLab administrator with the following command:

Feature.disable(:mr_tabs_position)

Creating merge requests

Learn how to create a merge request.

Reviewing and managing merge requests

See the features at your disposal to review and manage merge requests.

Testing and reports in merge requests

Learn about the options for testing and reports on the changes in a merge request.

Authorization for merge requests

There are two main ways to have a merge request flow with GitLab:

1. Working with protected branches in a single repository
2. Working with forks of an authoritative project

Learn more about the authorization for merge requests.