Merge requests

Merge requests (MRs) are the way you check source code changes into a branch. When you open a merge request, you can visualize and collaborate on the code changes before merge. Merge requests include:

  • 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.

To get started, read the introduction to merge requests.

Merge request tabs

Merge requests contain tabs at the top of the page to help you navigate to important parts of the merge request:

Merge request tab positions

  • Overview: Contains the description, notifications from pipelines, and a discussion area for comment threads and code suggestions. The right sidebar provides fields to add assignees, reviewers, labels, and a milestone to your work, and the merge request widgets area reports results from pipelines and tests.
  • Commits: Contains a list of commits added to this merge request. For more information, read Commits tab in merge requests.
  • Pipelines: If configured, contains a list of recent GitLab CI/CD pipelines and their status.
  • Changes: Contains the diffs of files changed by this merge request. You can configure the display.

View merge requests

You can view merge requests for a specific project, or for all projects in a group:

  • Specific project: Go to your project and select Merge requests.
  • All projects in a group: Go to your group and select Merge requests. If your group contains subgroups, this view also displays merge requests from the subgroup projects. GitLab displays a count of open merge requests in the left sidebar, but caches the value for groups with a large number of open merge requests.

GitLab displays open merge requests, with tabs to filter the list by open and closed status:

Project merge requests list view

You can search and filter, the results, or select a merge request to begin a review.

Merge request sidebar

The Overview tab of a merge request displays a sidebar. In this sidebar, you can assign, categorize, and track progress on a merge request:

  • Assignee: Designate the directly responsible individual (DRI) for a merge request. With multiple assignees, you can assign a merge request to more than one person at a time.
  • Reviewer: Designate a team member to review a merge request. Higher tiers can assign multiple reviewers, and require approvals from these reviewers.
  • Milestone: Track time-sensitive changes.
  • Time tracking: Time spent on a merge request.
  • Labels: Categorize a merge request and display it on appropriate issue boards.
  • Participants: A list of users participating or watching a merge request.
  • Notifications: A toggle to select whether or not to receive notifications for updates to a merge request.

Close a merge request

If you decide to permanently stop work on a merge request, GitLab recommends you close the merge request rather than delete it. Users with Developer, Maintainer, or Owner roles in a project can close merge requests in the project:

  1. Go to the merge request you want to close.
  2. Scroll to the comment box at the bottom of the page.
  3. Following the comment box, select Close merge request.

GitLab closes the merge request, but preserves records of the merge request, its comments, and any associated pipelines.

Delete a merge request

GitLab recommends you close, rather than delete, merge requests.

cautionYou cannot undo the deletion of a merge request.

To delete a merge request:

  1. Sign in to GitLab as a user with the project Owner role. Only users with this role can delete merge requests in a project.
  2. Go to the merge request you want to delete, and select Edit.
  3. Scroll to the bottom of the page, and select Delete merge request.

Merge request workflows

For 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.
  6. You request the approval from your manager.
  7. Your manager:
    1. Pushes a commit with their final review.
    2. Approves the merge request.
    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.

For 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. You preview your changes with Review Apps.
  4. You request your web designers for their implementation.
  5. You request the approval from your manager.
  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.