How to review a GitLab merge request on your phone

Most merge request reviews do not need a 27-inch monitor. A one-file fix, a dependency bump or a teammate’s second round of changes can be reviewed properly on a phone — if you follow an order that keeps you from missing things. This is that order, with GitLab’s own names for each button.

Step 1: Find what is waiting for you

Start from your To-Do List, not your email. GitLab adds a to-do when someone requests your review, mentions you, assigns you, or when your own merge request’s pipeline fails — so it is the one list of things that need you. (How it works: the GitLab To-Do List explained.) You can also filter the merge request list by Reviewer to see every review assigned to you.

Step 2: Read the overview before the code

On the merge request’s Overview tab, read three things before opening a single file:

• The description and the linked issue. What is this change supposed to do? You cannot judge a diff without knowing its intent.
• The pipeline. If it failed, the author may still be working on it — or the failure is part of what you should review.
• The merge widget. It lists what is blocking the merge right now: approvals, unresolved threads, conflicts, a required pipeline. Our guide to why a GitLab merge request can’t be merged explains each one.

Step 3: Go through the changes, file by file

Open the Changes tab and work through it one file at a time.

• On a phone, use the inline (unified) view; side-by-side needs the width of a landscape screen.
• Read tests first when there are any: they tell you what the author thinks the code should do.
• Large generated files (lock files, snapshots) can usually be skimmed. Spend your attention on logic.

Step 4: Comment on lines — as one review

Select a line’s number to comment on it; select a range to comment on several lines. Then, instead of Add comment now, choose Start a review:

• Your comments are saved as pending — only you can see them — and your status changes to show you have started reviewing.
• Keep adding with Add to review.
• For a small, concrete fix, write a suggestion instead of describing it, so the author can apply it in one click. See GitLab suggested changes.

Batching matters more on a phone than anywhere else: you can stop halfway, and nothing is published until you submit.

Step 5: Submit: Approve, Comment or Request changes

Open Your review and pick one:

• Approve — the change is good to merge. (The Approve button in the merge widget also submits any pending comments.)
• Comment — feedback without a verdict.
• Request changes — it needs another round. On Premium and Ultimate, this blocks the merge until you lift it or someone with permission bypasses it.

Add a one-line summary. The author gets one notification with everything in it.

On the Free tier, any Developer can approve, but approvals are optional and never block a merge. Required approval rules and Code Owners are Premium and Ultimate features.

Step 6: Merge, or let GitLab merge it

If you are the one merging and every check has passed, merge — choosing squash and delete source branch if your project uses them. If the pipeline is still running, select Set to auto-merge instead: GitLab merges the moment every merge check passes. A new commit to the merge request cancels auto-merge, so the latest code always gets a full check.

The browser or an app?

The mobile website can do everything above. What it lacks on a phone is reach: nothing tells you a review is waiting, and the diff was laid out for a wide screen.

That gap is what MergeBell was built for. Review requests arrive as push alerts from your To-Do List; a merge request opens on the same overview → changes → approve path, with every blocking reason listed before you tap Merge; and diffs never scroll the page sideways. Line comments, approve and merge (with squash and auto-merge) are free; review drafts with Request changes and suggestions are part of Pro. It is on Google Play for Android now, with iPhone coming soon.