GitLab Code Review

Code review means a teammate reads your changes before they join the main branch. Reviewers catch bugs, suggest cleaner approaches, and share knowledge. GitLab places the whole conversation inside the merge request, next to the code.

Think of an editor reading a draft article. The editor underlines weak sentences, leaves notes in the margin, and the writer fixes each note before publication.

The Review Cycle

  Author opens merge request
          ↓
  Reviewer reads the Changes tab
          ↓
  Reviewer leaves comments and suggestions
          ↓
  Author fixes code and replies
          ↓
  Reviewer resolves threads and approves
          ↓
  Pipeline passes → merge

Assign a Reviewer

Open the merge request and find Reviewers in the right sidebar. Select a teammate. The person receives a notification and a to-do item. The Assignee field names the author, and the Reviewer field names the person who checks the work.

Read the Changes Tab

The Changes tab shows every modified file. Red lines mark removed text, and green lines mark added text.

  - const total = price + tax;
  + const total = price + tax - discount;

Switch between inline and side-by-side views with the display setting. Mark each file as viewed with the checkbox so that progress stays visible in long reviews.

Leave a Comment on a Line

1. Hover over a line number in the Changes tab.
2. Select the comment icon that appears.
3. Type your note.
4. Select Add comment now to post at once or Start a review to hold the note.

Drag across several line numbers to comment on a block of code.

Batch Comments with a Review

Starting a review keeps your comments private as drafts. Nobody receives a notification for each note. Select Submit review when you finish, and the author receives everything in one message. This habit reduces notification noise.

Suggest Changes

A suggestion lets you propose exact replacement text. Select the suggestion icon in the comment box, and GitLab inserts a template.

```suggestion:-0+0
const total = price + tax - discount;
```

The author sees an Apply suggestion button. One click creates a commit with your wording. No copy and paste is needed.

Threads and Resolution

Action	Who	Meaning
Reply to a thread	Anyone	Continue the discussion
Resolve thread	Author or reviewer	The issue is settled
Reopen thread	Anyone	The issue needs more attention

Projects can require every thread to be resolved before merging. Open Settings → Merge requests and turn on the matching option.

Approve the Merge Request

Select Approve when the code meets the team standard. An approval signals confidence without blocking other reviewers. Paid plans add rules that demand a set number of approvals or specific approvers.

Write Helpful Review Comments

Weak Comment	Helpful Comment
This is wrong.	This loop skips the last item. Change the limit to length.
Bad name.	The name d hides the purpose. Rename it to deliveryDate.
Why?	What problem does this extra check solve? A short comment in the code would help future readers.

Mark minor style notes with the word "nit" so that the author knows these notes do not block the merge.

What Reviewers Check

• The code does what the linked issue describes.
• Tests cover the new behavior and the edge cases.
• Names and comments explain the intent.
• No secrets, passwords, or debug lines remain.
• The pipeline passes.
• The change stays small enough to review in one sitting.

Review as the Author

• Write a clear description with the reason for the change.
• Review your own diff before you request a review.
• Keep merge requests small, ideally under 400 changed lines.
• Reply to every comment, even with a short "Done".
• Thank reviewers; people notice kind teammates.

Review Etiquette

Talk about the code and avoid judging the person. Ask questions rather than give orders. Praise good solutions in the same thread where you point out problems. A respectful tone keeps teams eager to ask for reviews.