Approval rules in GitLab (Premium and Ultimate) set how many approvals a merge request needs and who can give them. To make them hold, stop committers from approving, forbid editing rules inside a merge request, and require at least one approver beyond the author on protected branches.
What approval rules do
Per GitLab's documentation, rules define the number of required approvals and the eligible approvers. They can be project defaults, set per merge request, or configured instance wide. A value of 0 makes a rule optional, and the maximum required is 100.
If there is no default rule, any user can approve. You can still set a minimum number in project settings, but a named approver group is stronger.
Settings that decide whether it is real
- Prevent merge request creator approval. Authors do not count as approvers by default. If someone disabled that project setting, authors can approve their own work.
- Prevent committers approval. Off by default, so a user who commits to a merge request can approve it. Turning it on closes a quiet loophole: a second person pushes a small commit, then approves.
- Prevent editing approval rules in merge requests. If this is disabled, administrators, the author (with Developer, Maintainer or Owner role) or Maintainers and Owners can override rules on a merge request. Administrators can enable the setting to stop overrides.
I could not confirm from the page I fetched whether approvals are removed on new commits, so check that option in your project settings.
Group approvers gotchas
- Only direct members of eligible groups can approve. Inherited members cannot.
- Group approvers need Developer access to the project, explicit or inherited. Otherwise they may get a 404 when opening the merge request.
- Planners and Reporters can approve only if they belong to a shared group and approval permissions are enabled for them.
Security approvals
On Ultimate, merge request approval policies can require a security approval. GitLab says these rules apply while the pipeline runs, which blocks merging before scans finish. After the pipeline completes, rules are checked again, and a bot comment explains next steps if scanners find issues requiring approval.
A baseline
- Create a default rule with a named group of reviewers and at least one required approval.
- Keep creator approval blocked.
- Turn on committer approval prevention.
- Block editing of approval rules in merge requests.
- Add code owner approval for sensitive paths. See protected branch setup.
- Review the group list twice a year.
Small team reality
If you have three engineers, a rule needing two other approvers can stall work. One approver other than the author is reasonable, and adding automated checks takes up the rest. The gate pull request demo shows how automated gating complements human review.
Safeguard policies, gates and guardrails automate that second layer. The free scan at gold.safeguard.sh/scan is a quick start.
Quick check
Can authors approve their own merge request?
Not by default. It only happens if the creator approval prevention setting was turned off.
Are approval rules available on the Free tier?
The documentation lists approval rules for Premium and Ultimate.
Sources
Last reviewed: 19 October 2026.
