Bitbucket Cloud branch permissions let you limit who can write to a branch and who can merge to it through pull requests, matched by branch name or pattern. When several rules match one branch, they all apply. A typical production setup allows merges only through pull requests and grants write access to almost nobody.
The two permission types
Atlassian's documentation describes two settings on the Branch permissions tab.
| Setting | What you choose | Effect |
|---|---|---|
| Write access | Only specific people or groups have write access | Limits who can push directly |
| Merge access via pull requests | Only specific people or groups have merge access | Limits who can merge a pull request |
The page notes that deleting a repository or rewriting its history requires write or admin permissions, and its example leaves no one able to delete or rewrite history on the protected branches. It does not name a separate switch for those two actions, so verify the behavior on a test repository before you rely on it.
Patterns
You can target a branch by name or by pattern in the By name or pattern field. Add a wildcard at either end, for example PROJECT-* to match PROJECT-1234. If your repository uses the branching model, you can also target branch types, such as release branches.
Overlap: everything that matches applies
If several restrictions match the same branch, all of them apply. A rule on * and a rule on main both govern main. That has two practical effects.
- A broad rule can silently tighten a branch. A team may wonder why they cannot push to a feature branch, and the answer is a wildcard rule written months ago.
- You cannot loosen a branch by adding a more specific rule, because the broader rule still applies. To loosen, edit or narrow the broad rule.
A configuration to start from
- Open More actions, then Settings, then Branch restrictions under Workflow.
- Add a restriction on your default branch.
- Set Write access to a very small group, or nobody if your process allows.
- Set Merge access via pull requests to the group that owns releases.
- Add a restriction for your release branches by pattern or branch type with the same rules.
- Add merge checks. See merge checks.
- Test with a throwaway account that holds only write access to the repository.
Reviewing the setup every quarter
Print the list of restrictions and ask, for each, who is in the groups and whether anyone left. Also look for gaps: a new long lived branch such as a maintenance release that no pattern covers. Admins matter too, as the page ties write and admin permission to history rewriting. Keep the admin list short.
Try it yourself
The gate demo shows a protected path where changes must pass a check before merging. Click through it and think about which of your branches have no such gate.
Click through it at your own pace, or open it full screen.
Quick check
If two rules match a branch, which wins?
Neither. Atlassian says all matching restrictions apply, so the effective rule is the combination.
How do I match all branches starting with release?
Use a pattern with a wildcard at the end, such as release*, in the By name or pattern field.
Safeguard policies and gates can add dependency checks to pull requests on branches you have restricted. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
