Table of contents

• Overview
• Step 1: Start on a feature branch
• Step 2: Push your branch
• Step 3: Open a merge request
• Step 4: Provide title and details
• Step 5: Draft vs ready MR
• Step 6: Review and update
• Step 7: Merge once approved
• Step 8: Post-merge cleanup
• Optional: Create MR from issue, web editor, or email
• Example: Issue → branch → MR
• Automation via CLI
• About stacking merge requests
• Wrapping up

Overview

A merge request (MR) in GitLab is how you propose, collaborate on, and finally merge code changes. You'll create a feature branch, push it, open an MR, review and iterate, then merge. GitLab supports some basic retargeting of dependent MRs, but for true stacked diffs—small, sequential changes where branches build on each other—you'll need tools like Graphite, available today on GitHub.

Step 1: Start on a feature branch

Begin with a focused branch name:

git checkout -b feature/awesome-widget
# edit your code...
git add .
git commit -m "add awesome widget support"

GitLab docs recommend clear branch naming for smooth MR creation.

Step 2: Push your branch

git push -u origin feature/awesome-widget

After pushing, GitLab often shows a prompt: "Create merge request."

Step 3: Open a merge request

You have options:

• Via the banner prompt
• Via Merge requests ▶ New merge request

1. Pick source (feature/awesome-widget) and target (main or master)
2. Click Compare branches and continue

Step 4: Provide title and details

• Title: Usually pre-filled from your commit/branch
• Description: Outline what — why — context, link issues (e.g. Closes #123)
• Assign reviewers, labels, milestone
• Optionally check delete source branch when merged

Step 5: Draft vs ready MR

If you're still working, mark as draft/WIP. When ready for feedback, mark it ready—via the UI or comment @gitlab-bot ready.

Step 6: Review and update

Reviewers comment in the diff. To act on feedback, amend your code, commit and git push again. The MR updates automatically.

Step 7: Merge once approved

After approving and successful CI:

• Click Merge
• Optionally enable auto-merge after pipeline passes
• Decide whether to delete the source branch

Step 8: Post-merge cleanup

Merged code flows through CI/CD pipelines, deploys may happen, and GitLab may delete the branch automatically. Merged issues close if described properly.

Optional: Create MR from issue, web editor, or email

GitLab supports:

• Creating branch & MR straight from an issue or GitLab task
• Opening an MR from the web editor
• Email-based MR creation (project admin must enable email)

Example: Issue → branch → MR

1. Issue #1234 tracks "Add login feature"
2. git checkout -b 1234-add-login-feature
3. Make changes, commit, push
4. Banner appears: Click Create merge request
5. GitLab fills title; add description, assign reviewer @alice, tag enhancement
6. Submit as draft, later mark ready, and iterate until approved

Automation via CLI

Use push options:

git push -o merge_request.create \
          -o merge_request.target=main \
          -o merge_request.remove_source_branch

This creates an MR automatically.

About stacking merge requests

GitLab can automatically retarget up to four open MRs: If MR 2 is based on MR 1, once MR 1 merges to main, MR 2's target shifts to main. But GitLab doesn't support real stacked diffs—where each MR is a small layer atop the previous. If you want that workflow, tools like Graphite (usable today with GitHub) offer true stacked PR support. Graphite gives you a dedicated CLI to create, rebase, submit stacks; a web app for managing them; and integration into GitHub's review process.

In short: GitLab gives you basic retargeting but not full stacking. For that, explore stacked PR ecosystems like Graphite on GitHub.

Wrapping up

Creating a merge request in GitLab is intuitive, whether via UI, branch name, issue, or CLI. You can manage the lifecycle—from draft to review to merge. But for full-featured stacked diffs, consider GitHub + Graphite.