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-12-26 22:10:19 +05:30
type: index, reference
2019-09-04 21:01:54 +05:30
---
2021-03-11 19:13:27 +05:30
# Merge requests **(FREE)**
2017-08-17 22:00:37 +05:30
2021-04-17 20:07:23 +05:30
Whenever you need to merge one branch into another branch with GitLab, you
must create a merge request (MR).
2017-08-17 22:00:37 +05:30
2021-04-17 20:07:23 +05:30
Using merge requests, you can visualize and collaborate on proposed changes to
source code. Merge requests display information about the proposed code changes,
including:
- A description of the request.
- Code changes and inline code reviews.
- Information about CI/CD pipelines.
- A comment section for discussion threads.
- The list of commits.
Based on your workflow, after review you can merge a merge request into its
target branch.
To get started, read the [introduction to merge requests ](getting_started.md ).
2017-09-10 17:25:29 +05:30
## Use cases
2020-04-22 19:07:51 +05:30
A. Consider you're a software developer working in a team:
2017-09-10 17:25:29 +05:30
1. You checkout a new branch, and submit your changes through a merge request
1. You gather feedback from your team
2020-07-28 23:09:34 +05:30
1. You work on the implementation optimizing code with [Code Quality reports ](code_quality.md )
2020-11-24 15:15:51 +05:30
1. You verify your changes with [Unit test reports ](../../../ci/unit_test_reports.md ) in GitLab CI/CD
2020-04-08 14:13:33 +05:30
1. You avoid using dependencies whose license is not compatible with your project with [License Compliance reports ](../../compliance/license_compliance/index.md ) ** (ULTIMATE)**
2019-12-26 22:10:19 +05:30
1. You request the [approval ](merge_request_approvals.md ) from your manager ** (STARTER)**
1. Your manager:
1. Pushes a commit with their final review
1. [Approves the merge request ](merge_request_approvals.md ) ** (STARTER)**
1. Sets it to [merge when pipeline succeeds ](merge_when_pipeline_succeeds.md )
2019-07-07 11:18:12 +05:30
1. Your changes get deployed to production with [manual actions ](../../../ci/yaml/README.md#whenmanual ) for GitLab CI/CD
2017-09-10 17:25:29 +05:30
1. Your implementations were successfully shipped to your customer
2019-07-31 22:56:46 +05:30
B. Consider you're a web developer writing a webpage for your company's website:
2017-09-10 17:25:29 +05:30
1. You checkout a new branch, and submit a new page through a merge request
1. You gather feedback from your reviewers
1. Your changes are previewed with [Review Apps ](../../../ci/review_apps/index.md )
1. You request your web designers for their implementation
2019-09-30 21:07:59 +05:30
1. You request the [approval ](merge_request_approvals.md ) from your manager ** (STARTER)**
2021-04-17 20:07:23 +05:30
1. Once approved, your merge request is [squashed and merged ](squash_and_merge.md ), and [deployed to staging with GitLab Pages ](https://about.gitlab.com/blog/2021/02/05/ci-deployment-and-environments/ )
2019-12-26 22:10:19 +05:30
1. Your production team [cherry picks ](cherry_pick_changes.md ) the merge commit into production
2020-01-01 13:55:28 +05:30
## Merge request navigation tabs at the top
2020-06-23 00:09:42 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/33813) in GitLab 12.6. This positioning is experimental.
2020-01-01 13:55:28 +05:30
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
2020-04-22 19:07:51 +05:30
to find these tabs, based on user feedback, we're experimenting with a new positioning
2020-01-01 13:55:28 +05:30
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:
```ruby
Feature.disable(:mr_tabs_position)
```
2019-12-26 22:10:19 +05:30
## Creating merge requests
2020-03-13 15:44:24 +05:30
Learn [how to create a merge request ](creating_merge_requests.md ).
2019-12-26 22:10:19 +05:30
## Reviewing and managing merge requests
2020-03-13 15:44:24 +05:30
See the features at your disposal to [review and manage merge requests ](reviewing_and_managing_merge_requests.md ).
2019-12-26 22:10:19 +05:30
## Testing and reports in merge requests
2020-06-23 00:09:42 +05:30
Learn about the options for [testing and reports ](testing_and_reports_in_merge_requests.md ) on the changes in a merge request.
2018-05-09 12:01:36 +05:30
2017-08-17 22:00:37 +05:30
## Authorization for merge requests
There are two main ways to have a merge request flow with GitLab:
2019-12-26 22:10:19 +05:30
1. Working with [protected branches ](../protected_branches.md ) in a single repository
2017-08-17 22:00:37 +05:30
1. Working with forks of an authoritative project
[Learn more about the authorization for merge requests. ](authorization_for_merge_requests.md )
