ContextQMD
Back to Gitlabhq

Merge request approval settings

doc/user/project/merge_requests/approvals/settings.md

18.11.211.3 KB
Original Source

{{< details >}}

  • Tier: Premium, Ultimate
  • Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

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 to apply those rules as a merge request moves toward completion.

Use any combination of these settings to configure approval limits for merge requests:

Edit merge request approval settings

To view or edit merge request approval settings for a single project:

  1. In the top bar, select Search or go to and find your project.
  2. Select Settings > Merge requests.
  3. Expand Approvals.

Cascade settings from the instance or top-level group

To simplify the management of approval rule settings, configure the approval rules at the broadest possible level. Rules created:

If a group or project inherits settings, you can't change them in the inheriting group or project. You must change the settings where they originated: the top-level group or instance.

Prevent approval by merge request creator

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

  1. In the top bar, select Search or go to and find your project.
  2. Select Settings > Merge requests.
  3. In the Merge request approvals section, scroll to Approval settings and clear the Prevent approval by merge request creator (author) checkbox.
  4. Select Save changes.

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

Prevent approvals by users who add commits

{{< history >}}

{{< /history >}}

By default, users who commit to a merge request (the committers) can still approve it. To prevent committers in your project (or your instance) from approving merge requests that are partially their own:

  1. In the top bar, select Search or go to and find your project.
  2. Select Settings > Merge requests.
  3. In the Merge request approvals section, scroll to Approval settings and select Prevent approvals by users who add commits. If this checkbox is cleared, an administrator has disabled it for your instance, and you can't change it for your project.
  4. Select Save changes.

Code owners who commit to a merge request cannot approve it, if the merge request affects files they own.

For more information, see the official Git documentation.

[!warning] If a merge request is rebased by someone other than the user who originally committed the changes, the commit history is rewritten with a new committer. This might enable users who previously committed changes in a merge request to now approve changes in it, as they are no longer a committer.

See also approving after rebase

Prevent editing approval rules in merge requests

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. In the top bar, select Search or go to and find your project.
  2. Select Settings > Merge requests.
  3. In the Merge request approvals section, scroll to Approval settings and select Prevent editing approval rules in merge requests.
  4. Select Save changes.

This change affects all open merge requests.

When you change this field, it can affect all open merge requests depending on the setting:

  • If users could edit approval rules previously, and you disable this behavior, GitLab updates all open merge requests to enforce the approval rules.
  • If users could not edit approval rules previously, and you enable approval rule editing, open merge requests remain unchanged. This preserves any changes already made to approval rules in those merge requests.

Require user re-authentication to approve

{{< history >}}

  • Requiring re-authentication by using SAML authentication for GitLab.com groups introduced in GitLab 16.6 with a flag named ff_require_saml_auth_to_approve. Disabled by default.
  • Requiring re-authentication by using SAML authentication for GitLab Self-Managed instances introduced in GitLab 16.7 with a flag named ff_require_saml_auth_to_approve. Disabled by default.
  • Enabled ff_require_saml_auth_to_approve by default in GitLab 16.8 for GitLab.com and GitLab Self-Managed instances.
  • Feature flag removed in GitLab 18.3

{{< /history >}}

[!flag] On GitLab Self-Managed, by default requiring re-authentication by using SAML authentication is available. To hide the feature, an administrator can disable the feature flag named ff_require_saml_auth_to_approve. On GitLab.com and GitLab Dedicated, this feature is available.

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

Prerequisites:

  • This setting is only available on top-level groups.
  1. In the top bar, select Search or go to and find your project.
  2. Enable password authentication and SAML authentication. For more information on:
  3. In the left sidebar, select Settings > Merge requests.
  4. In the Merge request approvals section, scroll to Approval settings and select Require user re-authentication (password or SAML) to approve.
  5. Select Save changes.

Remove all approvals when commits are added to the source branch

{{< details >}}

  • Tier: Premium, Ultimate
  • Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

By default, an approval on a merge request is removed when you add more changes after the approval.

GitLab uses git patch-id to identify diffs in merge requests. This value is a reasonably stable and unique identifier, and it enables smarter decisions about resetting approvals inside a merge request. When you push new changes to a merge request, the patch-id is evaluated against the previous patch-id to determine if the approvals should be reset. This enables GitLab to make better reset decisions when you perform commands like git rebase or git merge <target> on a feature branch.

To keep existing approvals after more changes are added to a merge request:

  1. In the top bar, select Search or go to and find your project.
  2. Select Settings > Merge requests.
  3. In the Merge request approvals section, scroll to Approval settings and clear the Remove all approvals checkbox.
  4. Select Save changes.

If you automate the creation and approval of merge requests, build in logic to ensure commits are processed fully before approving the merge request. This prevents an unintentional approval reset. For more information, see handle timing issues with automated approvals.

Remove approvals by Code Owners if their files changed

To remove approvals only from Code Owners whose files change in a new commit:

Prerequisites:

  • You must have the Maintainer or Owner role for a project.

To do this:

  1. In the top bar, select Search or go to and find your project.
  2. Select Settings > Merge requests.
  3. In the Merge request approvals section, scroll to Approval settings and select Remove approvals by Code Owners if their files changed.
  4. Select Save changes.