GitLab code review best practices in 2024

Welcome to this guide on GitLab code review best practices!We hope you'll find this guide useful, and if you're interested in the best way to manage your merge requests in GitLab, you should take a look at Axolo, which helps thousands of developers review merge requests faster in Slack (also incubated by Slack in 2023).

1. Code review in GitLab

Why approving a merge request in GitLab is important?

You can set your merge requests to require approval before they can be merged. While all users with Developer or higher permissions in GitLab Free can approve merge requests, these approvals are optional. GitLab Premium and GitLab Ultimate give you even more options:

Before work can be merged, establish the necessary rules regarding the number and type of approvers.

Create a list of users who act as code owners for specific files and require their approval before merging work.

Merge request approvals can be configured per project and at the group level. Administrators of self-managed GitLab Premium and GitLab Ultimate instances can also configure approvals for the entire instance.

Merge request approval rules in GitLab

You can set the minimum number of approvals required before code can be merged into your project using merge request approval rules. You can also use these rules to specify which users can approve work. Here are some examples of rules you can write:

• Work can always be approved by users with specific permissions.
• Code owners can approve work for files that they own.
• Users with specific permissions can approve work even if they do not have repository merge rights.
• Overriding approval rules on a specific merge request can be granted or denied to users with specific permissions.

You can also customize your rules to have additional merge request approval settings for greater control over the level of oversight and security your project requires.

How to approve a merge request in GitLab?

When an eligible approver visits an open merge request, GitLab displays one of the following buttons after the merge request body:

• Approve: The merge request has not yet received the necessary number of approvals.
• Approve additionally: The merge request has received the necessary number of approvals.
• Revoke approval: The user who is viewing the merge request has already approved it.

When adding a comment to a merge request, eligible approvers can also use the /approve quick action. If a user approves a merge request and is listed in the reviewer list in GitLab 13.10 or later, a green check mark () appears next to their name.

A merge request can merge once it has received the number and type of approvals you specify unless it is blocked for another reason. Other issues, such as merge conflicts, pending discussions, or a failed CI/CD pipeline, can block merge requests.

Prevent author approval in your project's settings to prevent merge request authors from approving their own merge requests.

When you enable approval rule overrides, merge requests created before the default approval rules change are unaffected. The only exceptions are changes to the rule's target branch.

You can find more detailed information in the Merge Request Approval section of the GitLab documentation.

GitLab reviewers

Set up GitLab default reviewers automatically

GitLab does not provide a way to automatically set reviewers on new merge requests, but you can ease this process by implementing code owner rules (next chapter).

GitLab code owners for merge request

Create a CODEOWNERS file to specify which users or shared groups are in charge of which files and directories in a repository. Each repository can only have one CODEOWNERS file. To set up your file:

Select the location where you want to save your CODEOWNERS file and create it, you have three possibilities:

• In the root of your repository
• In the directory .gitlab/
• In the docs/ folder

Enter commands in the file that follows one of the following patterns:

## Code Owners for a file
filename-path @username1 @username2

## Code Owners for a directory
directory-path/ @username1 @username2

## All group members as Code Owners for a file
filename @groupname

## All group members as Code Owners for a directory
directoryname/ @groupname

## Set up group members as Code Owners for the entire repository
* @groupname

After setting up your CODEOWNERS file, you will be able to find any potential reviewers in your eligible reviewer's section. More information about Code Owner in the dedicated GitLab documentation.

GitLab auto assign reviewers

GitLab does not have a built-in feature to automatically assign reviewers but we have created a side-project to help every GitLab users assign automatically their reviewers: Auto Assign Reviewer for GitLab by Axolo. You don't even need to create an Axolo account, you can use it on your own.

Use this tool to leverage CODEOWNERS and automatically assign reviewers to your merge requests. It's a simple and easy-to-use tool that will help you save time and improve your code review process.

Review, approval & comment in GitLab

Most other code versioning or code hosting software has a dedicated review feature within their pull/merge request. GitLab does not.

Inside GitLab, you can either approve a pull request or revoke your approval. If you wish to request changes to another developer, you need to either leave a comment in the Overview section of the merge request or comment directly on the code.

GitLab code review workflow

The GitLab code review workflow is simple.

1. Push your changes to GitLab using a terminal or the GitLab interface,
2. Open a merge request from your terminal or the GitLab interface,
3. Request reviewers to approve your merge request,
4. (optional) If you have set up CI/CD automation, wait for the green light before merging,
5. Reviewers will approve your merge request or request changes, change your code accordingly,
6. If all required reviewers have approved the merge request, you can now safely merge if there is no conflict with the base branch.

2. GitLab review apps

Built-in GitLab review apps have four main characteristics:

• By spinning up a dynamic environment for your merge requests, you can automatically provide a live preview of changes made in a feature branch.
• Allow designers and product managers to see your changes without having to check out your branch and test them in a sandbox environment.
• Are completely integrated with GitLab's DevOps LifeCycle.
• Give you the freedom to deploy your changes wherever you want.

How do review apps work?

A Review App is a branch-to-environment mapping. Access to the Review App is made available via a link on the branch's merge request.

The following is an example of a merge request with a dynamically set environment. A branch was successfully built in this example and deployed in a dynamic environment accessible by selecting the View app.

Following the addition of Review Apps to your workflow, you follow the branched Git flow. That is, push a branch and let the runner deploy the Review App based on the dynamic environment job's script definition. Then, the runner will build and deploy your web application.

To view the changes live, select the link in the merge request related to the branch. You have now set up a new review environment!

If you're interested, you can learn more in the dedicated GitLab Review App Documentation section.

Why are review apps important?

GitLab review apps for developers

Developers can begin collecting feedback much sooner. Submit a merge request and test your changes in real-time. When you push to master, you'll know that your changes have gone through CI testing as well as a live review where the team can ensure that everything works as expected.

GitLab review apps for the design, product, and marketing team

Giving feedback to designers, product managers, marketing colleagues, and others has never been easier. To preview changes, you won't need to check out branches or set up a staging environment. With Review Apps, you can see the live changes by clicking a link. Hopefully, this means you'll be able to provide more timely and accurate feedback.

3. GitLab CI/CD & automatic deployment

GitLab developed an internal CI/CD tool for software development following the continuous methodologies:

• Continuous Integration (CI)
• Continuous Delivery (CD)
• Continuous Deployment (CD)

Continuous Integration works by pushing small changes to your application’s codebase hosted in a Git repository, and, to every push, run a pipeline of scripts to build, test, and validate the code changes before merging them into the main branch.

Continuous Delivery and Deployment consist of a step further CI, deploying your application to production at every push to the default branch of the repository.

These methodologies allow you to catch bugs and errors early in the development cycle, ensuring that all the code deployed to production complies with the code standards you established for your app.

For more detailed information on GitLab CI/CD, you can watch a Demo: CI/CD with GitLab made by the GitLab team or surf through the CI/CD Documentation.