Blog News Code review made easier thanks to merge request reviewers in GitLab 13.7
Published on: October 13, 2020
4 min read

Code review made easier thanks to merge request reviewers in GitLab 13.7

Code review is a critically important part of the software development, but it can be hard – and time consuming – to arrange. That's where our new merge request reviewers feature comes in. Here's what to look for in our 13.7 release.


Edit: This feature was originally planned for the 13.5 release but has now been rescheduled to the 13.7 release in order to address some performance improvements.

Requesting a code review is an important part of contributing code to any software project. However, deciding who should review your code and asking for a review are no easy tasks. Historically, teams making use of merge requests for their code review needs have used the "assignee" field for both authors and reviewers but this makes it hard for others to determine who's doing what on a merge request; for example, consider a merge request with a single author and 2 reviewers. If all parties are on the “assignee” field at once, it is hard for an external user to find out who to reach out for something specific.

The back-and-forth between authors and reviewers causes the author to go through MR history to find the original reviewer as well as unnecessary assigning back and forth from everyone. Peers who are coming on to assist cannot easily find relevant players for this merge request. Lastly, the merge request author does not know if a reviewer has reviewed but not approved the changes, or if more work is needed from them.

GitLab code reviews

Whether or not code is good quality can’t be taken on faith; code quality needs to be checked. GitLab makes it easy to collaborate on code reviews within a merge request. In GitLab, users can assign one or more code reviewers to a source project. Collaboration in merge requests with GitLab reviewers helps deployments go more smoothly. The code reviewer option in GitLab is available on GitLab Premium and GitLab Ultimate.

Merge requests and code reviews

The merge request Reviewers feature in GitLab allows for a review of your work and to see the critique progress status. The “suggest changes” feature lets a colleague suggest alterations that the original author can choose to accept or not, just with the click of a button. And, of course, every change made to a block of code can be reviewed before it goes live.

Feature branches and code reviews

Creating a new feature branch or new code automatically kicks off a merge request, and that is the place to request a code review. In the MR, inline code reviews can be performed either on a single line or multiple lines of code, and a reviewer can leave comments. A feature branch allows for changes to be made to the codebase without them moving onto the main default branch.

After the merge request and code review are complete, feature branches can be deleted to keep the source code repository clean as possible. It’s also possible to add time tracking to an MR to discern how long the process, including the code review, takes from beginning to end.

The merge request widget helps delete these feature branches once a merge request and code review are done. This can be set up to happen as you create the initial MR by choosing the “delete source branch when merge request accepted” selection. That way, the branch gets deleted after the MR is merged.

Improving code reviews

To bridge these gaps, GitLab 13.7 introduces merge request "reviewers," which easily allows authors to request a review as well as see the status of the review. By simply selecting one or more users from the "reviewers" field, the assigned reviewers will receive a notification of the request to review the merge request. This makes it easy to determine the relevant roles for the users involved in the merge request, as well as formally requesting a review from a peer.

Merge request reviewers Screenshot from upcoming GitLab 13.7 release

What's next

Future improvements include suggesting the most relevant reviewers as well as streamlining the approval rules experience when paired with reviewers.

We are excited to see this feature ship soon to and for self-managed users on October 22nd. As always, we encourage you to participate in the conversation by visiting the related reviewers epic in the GitLab project.

Cover image by Kevin Ku on Unsplash

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

Find out which plan works best for your team

Learn about pricing

Learn about what GitLab can do for your team

Talk to an expert