GitLab push rules are pre-receive checks that can reject unsigned commits, files that look like secrets, nonconforming branch names or commit messages, and oversized files before they enter the repository. They need the Premium or Ultimate tier and complement protected branches, which control who can push where.
What the rules cover
GitLab describes push rules as pre-receive Git hooks you enable through a user interface. Available groups include:
- Verify users: reject unverified committers or inconsistent author names, and enforce an author email pattern.
- Commit messages: require or reject messages matching a regular expression.
- Branch names: enforce a pattern.
- Unintended consequences: reject unsigned commits and block deleting tags with a push.
- Files: block secret files such as SSH keys and key files, prohibit names matching a pattern, and set a maximum file size.
- Developer Certificate of Origin: require a Signed-off-by line.
How they differ from protected branches
Protected branches decide who may push or merge to a branch. Push rules look inside the push itself. One answers who, the other answers what. A repository that uses both stops a trusted person from pushing a private key file, which a branch rule alone would allow.
Where to configure
Administrators set global rules that act as a template for projects created later. Group maintainers set predefined rules that projects inherit, though not subgroups. Project maintainers set project rules, which are independent copies. Regular expressions use RE2 syntax and are limited to 511 characters. Push rules are bypassed during fork synchronization, which is worth knowing when you review forks.
Existing projects are not updated by the global template, so run a one time sweep when you introduce it.
Rolling them out
- Start with file rules for key and certificate names, which have few false positives.
- Add the reject unsigned commits rule on release repositories first.
- Add branch name and commit message rules only if they serve a tool, such as a ticket link or release automation.
- Tell developers the error text they will see, since a rejected push is confusing without context.
- Review exceptions monthly.
Push rules catch obvious mistakes, not every secret. Keep a scanner in the pipeline as well, since file names say little about content.
Where Safeguard fits
Safeguard scans dependencies and builds an SBOM, and its policies and gates can block a pull request that adds a known-vulnerable package. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Open the gate demo and compare a check that runs after a pull request opens with the push time checks described above.
Click through it at your own pace, or open it full screen.
Quick check
Which tiers include push rules?
Premium and Ultimate, on GitLab.com, Self-Managed and Dedicated.
Do push rules replace secret scanning?
No. File name rules catch obvious files. Content scanning is a separate control.
Sources
Last reviewed: 19 October 2026.
