Restrict Creation of Branches to Certain Patterns
Platform Notice: Cloud - This article applies to Atlassian products on the cloud platform.
Summary
In certain use cases, there is a requirement to limit users from creating branches based on specific branch patterns. This document elaborates on how to achieve this restriction, ensuring controlled access to branch creation.
Solution
To implement branch creation restrictions, one can utilize the powerful feature of "Branch Permissions" in Bitbucket Cloud.
Example Scenario: Let's consider a situation where it is necessary to restrict branch creation to only the patterns "main", "test" and "test-123," while all other branch creations should be restricted.
To accomplish this, the following branch permissions can be set:
Pattern "*" (No Write and Pull Request Merge):
- With this permission, users are restricted from creating branches with patterns other than "main" and "test-123".
Main Branch (Allow Write and Pull Request Merge):
- By enabling this permission for certain users or groups, they gain the ability to create branches with the pattern "main" and perform pull request merges.
Test* Branch Pattern (Allow Write and Pull Request Merge for Certain Users):
- Here, specific users or groups are granted write and pull request merge permissions for branches matching the pattern "test*" (e.g., test-123, test-feature, etc.).
- Here, specific users or groups are granted write and pull request merge permissions for branches matching the pattern "test*" (e.g., test-123, test-feature, etc.).
By configuring these branch permissions in Bitbucket Cloud, organizations can ensure controlled access to branch creation and maintain a structured branching strategy that aligns with their development workflow.
Note
One additional important point to consider is the issue of branch permissions overlap. Overlapping branch permissions can occur when specific permissions are set for a branch name, such as "main," and at the same time, wildcard (*) branch patterns are also defined in the permissions. In such cases, both the specific permission for the named branch and the wildcard permission would apply to the branch with the matching name.
Here are some examples to illustrate the results of overlapping permission definitions:
Wildcard (*) branch patterns | Specific ("main") branch name | What's enforced for branches included in both restrictions |
|---|---|---|
User or group restrictions (write or merge access) | ||
No users or groups listed | Alana | Only Alana has access |
Everybody | Alana | Only Alana has access |
Alana | Harvey | Both Alana and Harvey have access |
Alana | No users or groups | Only Alana has access |
Alana | Everybody | Only Alana has access |
It's essential to be mindful of these overlaps to ensure proper branch access control.
If the above instructions are not sufficient for your use case, please raise a support ticket or raise a community support ticket for further assistance with this.