GitLab Merge Requests

A merge request (MR) is a formal proposal to bring changes from one branch into another. It creates a space where teammates review code, leave comments, run automated checks, and approve the change before it reaches the main branch.

The Purpose of a Merge Request

  WITHOUT merge requests:
  Dev pushes directly to main → untested code reaches production → bugs appear 🐛

  WITH merge requests:
  Dev pushes to feature branch
       ↓
  Opens merge request → team reviews → CI/CD tests run
       ↓
  Approved? → Merges into main → production stays stable ✅

Creating a Merge Request

From GitLab Interface

After pushing a branch, GitLab shows a blue banner at the top of your project: "You just pushed branch feature/add-search — Create merge request?". Click that button. Fill in the title and description, then submit.

From the Branches Page

Go to Repository → Branches, find your branch, and click the Merge request button next to it.

Anatomy of a Merge Request

  ┌─────────────────────────────────────────────────────────┐
  │ Title: Add search bar to header                         │
  │ Author: Riya → Target: main ← Source: feature/search    │
  ├─────────────────────────────────────────────────────────┤
  │ Description                                             │
  │   What changed, why it changed, how to test it          │
  ├─────────────────────────────────────────────────────────┤
  │ Assignees / Reviewers / Labels / Milestone              │
  ├─────────────────────────────────────────────────────────┤
  │ Pipeline: ✅ passed   │  Approvals: 1 of 2 required     │  
  ├─────────────────────────────────────────────────────────┤
  │ Changes (diff view)   │  Discussion tab (comments)      │
  └─────────────────────────────────────────────────────────┘

Writing a Good MR Description

A clear description saves reviewers time. Include:

• What changed — "Added a search input in the header component"
• Why — "Resolves issue #42 — users requested quick search access"
• How to test — "Open the home page, type in the search bar, press Enter"
• Screenshots — paste a before/after screenshot for UI changes

GitLab supports MR templates. Admins create a template file at .gitlab/merge_request_templates/Default.md, and GitLab pre-fills the description box with it for every new MR.

The Diff View — Reading Code Changes

The Changes tab shows exactly what was added, removed, or modified. Lines in green were added. Lines in red were removed.

  --- a/src/header.js
  +++ b/src/header.js

  - <div class="logo">
  + <div class="logo">
  +   <input type="text" placeholder="Search..." />

  Lines starting with + are new.
  Lines starting with - were deleted.

Leaving Inline Comments

Reviewers can click any line in the diff to leave a comment right next to that line. This keeps feedback specific and easy to find.

  Line 14: + <input type="text" placeholder="Search..." />
            💬 "Should this have an aria-label for accessibility?"
               → Riya replies: "Good catch! I'll add it."
               → Resolved ✅

Assignees vs Reviewers

MR Approval Rules

Project maintainers can require a minimum number of approvals before any MR can merge. This prevents a single person from merging their own code unreviewed.

  Approval rule: 2 reviewers must approve
  ─────────────────────────────────────────
  Sara approved ✅
  Arjun approved ✅
  ─────────────────────────────────────────
  Merge button unlocked → MR can now be merged

Set approval rules at Settings → Merge requests → Approval rules.

Draft Merge Requests

Prefix the MR title with Draft: to signal that it is not ready for review. GitLab blocks the merge button on draft MRs. Remove "Draft:" from the title when the work is ready.

  Draft: Add search bar to header     ← blocked, in progress
  Add search bar to header            ← ready to review

Merge Strategies
When you click Merge, GitLab offers three strategies:

  

    

      
Strategy
      
What It Does
      
When to Use
    
  
  

    

      
Merge commit
      
Creates a new commit that joins both branches
      
Default; keeps full history
    
    

      
Squash and merge
      
Combines all MR commits into one before merging
      
Keeps main branch history clean
    
    

      
Rebase and merge
      
Replays commits on top of main with no merge commit
      
Linear history preferred
    
  


Closing Issues with an MR
Type Closes #42 anywhere in the MR description. When the MR merges, GitLab automatically closes issue #42. No manual close needed.
  MR Description:
  "Add search bar to header. Closes #42."

  After merge:
  Issue #42 → automatically closed ✅
The Delete Branch Option After Merge
After clicking Merge, GitLab shows a checkbox: Delete source branch. Check it. The feature branch has done its job and deleting it keeps your branch list tidy.
Reverting a Merged MR
If a merged MR causes a problem, click the Revert button on the closed MR page. GitLab creates a new branch that undoes all the changes and opens a new MR for you to review and merge.
  MR #47 merged → bug discovered in production
       ↓
  Click "Revert" on MR #47
       ↓
  New MR #48 "Revert MR #47" created automatically
       ↓
  Review and merge MR #48 → bug removed from production ✅