Skip to main content
GitLab Merge Requests (MRs) are the cornerstone of collaborative development in GitLab. They enable teams to propose, review, and integrate code changes from one branch into another. While MRs serve the same purpose as GitHub Pull Requests, they use different terminology and offer seamless integration with GitLab’s built-in CI/CD.

What Is a Merge Request?

A Merge Request lets you:
  • Propose changes from a source branch to a target branch (typically main or master).
  • Collaborate through comments, inline code discussions, and approvals.
  • Enforce quality gates by requiring passing CI/CD pipelines before merging.
Give your Merge Request a clear title and description. Assign reviewers early to accelerate feedback.

GitLab vs. GitHub: Core Concepts

Despite these differences, both platforms follow a similar review workflow:
  1. Create a feature branch
  2. Commit your code
  3. Submit for review
  4. Discuss and revise
  5. Merge into the main codebase

Typical Merge Request Workflow

1. Create a Feature Branch

2. Develop and Commit Changes

3. Push to the Remote Repository

4. Open a Merge Request

  1. Go to Merge RequestsNew merge request in your GitLab project.
  2. Select feature-xyz as the Source branch and main as the Target branch.
  3. Add a descriptive title and detailed description of your changes.

5. Review and Iterate

  • Reviewers leave comments or suggestions.
  • Address feedback by pushing follow-up commits:

6. Merge When Ready

Once all approvals are in place and CI pipelines succeed, click Merge.
Do not merge if the pipeline has failed. Failing tests or lint errors will propagate into your main branch.

Watch Video