Merge request approval settings

You can configure the settings for merge request approvals to ensure the approval rules meet your use case. You can also configure approval rules, which define the number and type of users who must approve work before it’s merged. Merge request approval settings define how those rules are applied as a merge request moves toward completion.

Edit merge request approval settings

To view or edit merge request approval settings:

  1. Go to your project and select Settings > General.
  2. Expand Merge request (MR) approvals.

In this section of general settings, you can configure the settings described on this page.

Prevent overrides of default approvals

By default, users can override the approval rules you create for a project on a per-merge request basis. If you don’t want users to change approval rules on merge requests, you can disable this setting:

  1. Go to your project and select Settings > General.
  2. Expand Merge request (MR) approvals.
  3. Select the Prevent users from modifying MR approval rules in merge requests checkbox.
  4. Select Save changes.

TODO This change affects all open merge requests.

Reset approvals on push

By default, an approval on a merge request remains in place, even if you add more changes after the approval. If you want to remove all existing approvals on a merge request when more changes are added to it:

  1. Go to your project and select Settings > General.
  2. Expand Merge request (MR) approvals.
  3. Select the Require new approvals when new commits are added to an MR checkbox.
  4. Select Save changes.

Approvals aren’t reset when a merge request is rebased from the UI However, approvals are reset if the target branch is changed.

Prevent authors from approving their own work

Version history
  • Introduced in GitLab 11.3.
  • Moved to GitLab Premium in 13.9.

By default, the author of a merge request cannot approve it. To change this setting:

  1. Go to your project and select Settings > General.
  2. Expand Merge request (MR) approvals.
  3. Clear the Prevent MR approval by the author checkbox.
  4. Select Save changes.

Authors can edit the approval rule in an individual merge request and override this setting, unless you configure one of these options:

Prevent committers from approving their own work

Version history
  • Introduced in GitLab 11.10.
  • Moved to GitLab Premium in 13.9.

By default, users who commit to a merge request can still approve it. At both the project level or instance level you can prevent committers from approving merge requests that are partially their own. To do this:

  1. Go to your project and select Settings > General.
  2. Expand Merge request (MR) approvals.
  3. Select the Prevent MR approvals from users who make commits to the MR checkbox. If this checkbox is cleared, an administrator has disabled it at the instance level, and it can’t be changed at the project level.
  4. Select Save changes.

Even with this configuration, code owners who contribute to a merge request can approve merge requests that affect files they own.

To learn more about the differences between authors and committers, read the official Git documentation for an explanation.

Require authentication for approvals

Version history
  • Introduced in GitLab 12.0.
  • Moved to GitLab Premium in 13.9.

You can force potential approvers to first authenticate with a password. This permission enables an electronic signature for approvals, such as the one defined by Code of Federal Regulations (CFR) Part 11):

  1. Enable password authentication for the web interface, as described in the sign-in restrictions documentation.
  2. Go to your project and select Settings > General.
  3. Expand Merge request (MR) approvals.
  4. Select the Require user password for approvals checkbox.
  5. Select Save changes.

Security approvals in merge requests

You can require that a member of your security team approves a merge request if a merge request could introduce a vulnerability. To learn more, see Security approvals in merge requests.