Protected branches, tags and push rules
Protected branches, protected tags and push rules decide who can change a repository and what a commit must look like. This page is for project administrators who set the rules, and for members who see a push refused.
The rules are set per repository, and you need to be a project administrator to change repository settings. They apply to every way of changing a repository: Git over HTTPS, Git over SSH, the web editor, branch creation, merges and rebases.
Protect a branch
Section titled “Protect a branch”A rule names a branch exactly or with a * wildcard, such as release/*.
| Setting | Options |
|---|---|
| Branch | An exact name, or a pattern with * |
| Allowed to push | No one, administrators, or members and administrators |
| Allowed to merge | No one, administrators, or members and administrators |
| Allow force push | On or off |
| Require code owner approval | On or off, see Merge requests and approvals |
How the rules combine:
- When several rules match a branch, the most permissive one applies.
- Without a rule, the default branch keeps an implicit protection that lets only administrators push.
- A protected branch cannot be deleted.
- Writers can merge into unprotected branches. A protected target branch needs the merge role.
- Rebasing a protected source branch needs the force-push permission.
A refused push is answered inside the Git protocol, so Git prints the reason from the rule.
! [remote rejected] main -> main (<reason from the rule>)If a direct push to a protected branch is refused, push a feature branch and open a merge request instead.
Protect a tag
Section titled “Protect a tag”Protected tags have roles for creating, deleting and running. They apply to tags that you push with Git and to tags that you create or delete in the web interface. Releases that create a tag go through the same rules, see Environments, deployments and releases.
Add push rules
Section titled “Add push rules”Push rules check the commits in a push. Patterns are RE2 regular expressions.
| Rule | What it checks |
|---|---|
| Commit message must match | A pattern that every commit message needs to match |
| Commit message must not match | A pattern that no commit message may match |
| Branch name | A pattern for the names of new branches |
| Author email | A pattern for the author’s e-mail address |
| Author is an Orbit user | The commit author must be an Orbit user |
| File name | A pattern for file names that are refused |
| Secret files | Refuses private keys and credential files |
| Maximum file size | Refuses larger files |
Push rules check only commits that are new to the repository. Merge and rebase commits that Forge creates are exempt.
Secret push protection
Section titled “Secret push protection”A further push rule refuses added or changed files that contain a value matching Forge’s secret rules. It checks files up to 1 MiB each and up to 64 MiB per push.
- It applies to pushes over HTTPS and SSH and to commits made in the web editor.
- The rules recognise keys and tokens for AWS, GitHub, GitLab, Slack, Stripe and Google. They also recognise private keys, Forge access and job tokens, JWTs and hard-coded password assignments. Obvious placeholders are skipped.
- The refusal names the rule, the file, the line and the commit. It never shows the value.
The same secret rules power secret detection in Security scanning and governance.