Merge request approval settings | GitLab Docs
https://docs.gitlab.com/user/project/merge_requests/approvals/settings/ • 51 KB fetched
Open original page
Merge request approval settings | GitLab Docs Skip to main content
Go to GitLab Docs homepage
What's new?
What's new?
Get free trial
Toggle menu
* Use GitLab
* GitLab Duo
* GitLab Orbit
* Extend
* Install
* Administer
* Subscribe
* Contribute
* Solutions
Getting started
Tutorials
Manage your organization
Organize work with projects
Plan and track work
Manage authentication and authorization
Use Git
Manage your code
Getting started
Repositories
Merge requests
Commits
Changes
Create merge requests
Reviewing and managing merge requests
Merge requests homepage
Tutorial: Understand your merge requests on the Merge requests homepage
Merge request widgets
Stacked merge requests
Suggestions
GitLab Duo in merge requests
Approvals
Approval rules
Approval settings
Automatic reviewer assignment
Versions
Manage merge requests
Tutorial: Review a merge request
Workflows
Export merge requests to CSV
Reports
Troubleshooting
Remote development
Use CI/CD to build your application
Secure your application
Deploy and release your application
Manage your infrastructure
Monitor your application
Analyze GitLab usage
Release notes
Feature support
Find your GitLab version
* GitLab Docs
/
* Use GitLab
/
* Manage your code
/
* Merge requests
/
* Reviewing and managing m…
/
* Approvals
/
* Approval settings
Help us learn about your current experience with the documentation. Take the survey .
Merge request approval settings
* Tier : Premium, Ultimate
* Offering : GitLab.com, GitLab Self-Managed, GitLab Dedicated
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:
* Prevent approval by merge request creator :
Prevents the author of a merge request from approving it.
* Prevent approvals by users who add commits :
Prevents users who add commits to a merge request from also approving it.
* Prevent editing approval rules in merge requests :
Prevents users from overriding project approval rules on merge requests.
* Require user re-authentication (password or SAML) to approve :
Force potential approvers to first authenticate with either a password or with SAML.
* Code Owner approval removals: Define what happens to existing approvals when
commits are added to the merge request.
* Keep approvals : Do not remove any approvals.
* Remove all approvals :
Remove all existing approvals.
* Remove approvals by Code Owners if their files changed :
If a Code Owner approves a merge request, and a later commit changes files
they are a Code Owner for, their approval is removed.
Edit merge request approval settings
To view or edit merge request approval settings for a single project:
* In the top bar, select Search or go to and find your project.
* In the left sidebar, select Settings > Merge requests .
* Expand Approvals .
Cascade settings from the instance or top-level group
To simplify the management of approval rule settings, configure them as broadly as possible.
Settings configured:
* For your instance apply to all groups
and projects on the instance.
* For a top-level group apply to
its subgroups and projects.
How a setting cascades depends on where it s configured:
* A setting configured for your instance locks the equivalent setting for all groups and projects.
You cannot change the inherited setting in a group or project.
* A setting configured for a top-level group cascades to its subgroups and projects:
* When a prevention setting is enabled for a group, the equivalent project setting is
locked. Project Maintainers cannot change it.
* When a prevention setting is disabled for a group, project Maintainers can configure it
for individual projects.
Prevent approval by merge request creator
By default, the creator of a merge request (author) cannot approve it. To change this setting:
* In the top bar, select Search or go to and find your project.
* In the left sidebar, select Settings > Merge requests .
* In the Merge request approvals section, scroll to Approval settings and
clear the Prevent approval by merge request creator (author) checkbox.
* 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 overrides of default approvals for your project.
* (GitLab Self-Managed instances only) Prevent overrides of default approvals
for your instance . When configured
for your instance, you can t edit this setting on projects or individual
merge requests.
Prevent approvals by users who add commits
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:
* In the top bar, select Search or go to and find your project.
* In the left sidebar, select Settings > Merge requests .
* 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.
* 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 .
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:
* In the top bar, select Search or go to and find your project.
* In the left sidebar, select Settings > Merge requests .
* In the Merge request approvals section, scroll to Approval settings and
select Prevent editing approval rules in merge requests .
* Select Save changes .
This setting has a different scope at each level. For a project or group, it prevents approval
rule overrides per merge request. The approval rules list in project settings remains editable.
To also prevent project Maintainers from editing the approval rules list, an administrator must
enable
Prevent editing approval rules in projects and merge requests
for your instance.
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 feature 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 feature 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
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.
* In the top bar, select Search or go to and find your project.
* Enable password authentication and SAML authentication. For more information on:
* Password authentication, see
sign-in restrictions documentation .
* SAML authentication for GitLab.com groups, see
SAML SSO for GitLab.com groups documentation .
* SAML authentication for GitLab Self-Managed instances, see
SAML SSO for GitLab Self-Managed .
* In the left sidebar, select Settings > Merge requests .
* In the Merge request approvals section, scroll to Approval settings and
select Require user re-authentication (password or SAML) to approve .
* Select Save changes .
Remove all approvals when commits are added to the source branch
* Tier : Premium, Ultimate
* Offering : GitLab.com, GitLab Self-Managed, GitLab Dedicated
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:
* In the top bar, select Search or go to and find your project.
* In the left sidebar, select Settings > Merge requests .
* In the Merge request approvals section, scroll to Approval settings and
clear the Remove all approvals checkbox.
* 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:
* In the top bar, select Search or go to and find your project.
* In the left sidebar, select Settings > Merge requests .
* In the Merge request approvals section, scroll to Approval settings and
select Remove approvals by Code Owners if their files changed .
* Select Save changes .
Related topics
* Merge request approval settings for your instance
* Compliance center
* Merge request approvals API
* Merge request approval settings API
* Edit merge request approval settings
* Cascade settings from the instance or top-level group
* Prevent approval by merge request creator
* Prevent approvals by users who add commits
* Prevent editing approval rules in merge requests
* Require user re-authentication to approve
* Remove all approvals when commits are added to the source branch
* Remove approvals by Code Owners if their files changed
* Related topics
* Facebook
* LinkedIn
* Twitter
* YouTube
Company
* About GitLab
* View pricing
* Try GitLab for free
Feedback
* View page source
* Edit in Web IDE
* Contribute to GitLab
* Suggest updates
Help & Community
* Get certified
* Get support
* Post on the GitLab forum
Resources
* Terms
* Privacy statement
* Use of generative AI
* Acceptable use of user licenses
*
Links found on this page
- Skip to main content [direct]
- Go to GitLab Docs homepage [direct]
- What's new? [direct]
- Get free trial [direct]
- Use GitLab [direct]
- GitLab Duo [direct]
- GitLab Orbit [direct]
- Extend [direct]
- Install [direct]
- Administer [direct]
- Subscribe [direct]
- Contribute [direct]
- Solutions [direct]
- Getting started [direct]
- Tutorials [direct]
- Manage your organization [direct]
- Organize work with projects [direct]
- Plan and track work [direct]
- Manage authentication and authorization [direct]
- Use Git [direct]
- Manage your code [direct]
- Getting started [direct]
- Repositories [direct]
- Merge requests [direct]
- Commits [direct]
- Changes [direct]
- Create merge requests [direct]
- Reviewing and managing merge requests [direct]
- Merge requests homepage [direct]
- Tutorial: Understand your merge requests on the Merge requests homepage [direct]
- Merge request widgets [direct]
- Stacked merge requests [direct]
- Suggestions [direct]
- GitLab Duo in merge requests [direct]
- Approvals [direct]
- Approval rules [direct]
- Automatic reviewer assignment [direct]
- Versions [direct]
- Manage merge requests [direct]
- Tutorial: Review a merge request [direct]
- Workflows [direct]
- Export merge requests to CSV [direct]
- Reports [direct]
- Troubleshooting [direct]
- Remote development [direct]
- Use CI/CD to build your application [direct]
- Secure your application [direct]
- Deploy and release your application [direct]
- Manage your infrastructure [direct]
- Monitor your application [direct]
- Analyze GitLab usage [direct]
- Release notes [direct]
- Feature support [direct]
- Find your GitLab version [direct]
- Take the survey [direct]
- For your instance [direct]
- top-level group [direct]
- Code owners [direct]
- official Git documentation [direct]
- approving after rebase [direct]
- introduced [direct]
- with a feature flag [direct]
- introduced [direct]
- Enabled ff_require_saml_auth_to_approve by default [direct]
- Code of Federal Regulations (CFR) Part 11 [direct]
- sign-in restrictions documentation [direct]
- SAML SSO for GitLab.com groups documentation [direct]
- SAML SSO for GitLab Self-Managed [direct]
- git patch-id [direct]
- handle timing issues with automated approvals [direct]
- Compliance center [direct]
- Merge request approval settings API [direct]
- Facebook [direct]
- LinkedIn [direct]
- Twitter [direct]
- YouTube [direct]
- About GitLab [direct]
- View pricing [direct]
- Try GitLab for free [direct]
- View page source [direct]