We just migrated hundreds of repositories from local Bitbucket to Cloud to discover such basic features are missing- which is rather shocking considering they are both called Bitbucket but under the hood they must be completely different solutions. 
So now after just few weeks use, we’re considering moving away from it to competitors. 

We also face this issue with release/* branches. We want our devs to be able to open a release/x branch, but protect it with PRs.

Day 1 of asking Atlassian to fix this issue that has already graduated kindergarten.

57465700c4e1 I have the same issue as 5e56b659bed7 and others on this ticket - we protect branches using prefix patterns so that for example all hotfix/* or all release/* branches are protected from direct write/push (and deletion).  We don't use a long-running "hotfix" branch, we create new branches for each release or hotfix (we also happen to protect shared "project/*" branches the same way). 

We also have to have a special pipeline that run with elevated permissions (that have write access for those branch patterns) to create such branches as regular developers are not able to do so.

This ticket has been open since 2017!!!  How much more interest does it need to gather??

57465700c4e1 You do misunderstand the requirement. :/

What I (and I think everyone else) on this thread is asking for is for a different scenario than you describe. I never need or want a `hotfix` branch; but I do need a `hotfix/PLAT-1234` branch that anyone can create but no one can push to.

With the tools as they currently are, this is what my team does when we need to make a hotfix:

1. A dev work locally in a branch such as `fix/PLAT-1234-change-the-thing` and then pushes that up to the remote.
2. That dev then starts a custom tool we built on Jenkins that runs a script as a Bitbucket Admin user and it creates a `hotfix/10.0.1` branch from `main`.
3. They open a PR from `fix/PLAT-1234-change-the-thing` to `hotfix/10.0.1`.
4. Other devs look at the PR and approve. Builds of the `hotfix/10.0.1` branch are tested and QA signs off by approving the PR.
5. the PR is merged to `hotfix/10.0.1`
6. The dev opens a new PR from `hotfix/10.0.1` to `main` and triggers a Jenkins "release" build on that PR. If the automated tests all pass there, the Jenkins build merges that PR into main, tags that commit in `main` with the `10.0.1` tag, and then the tagged main build is released as version 10.0.1.

If Bitbucket had a branch restriction where anyone could create the branch but only admins could push to it (or no one could push to it), we wouldn't have needed to create a custom tool for step 2 above, because any of the devs could just create the `hotfix/10.0.1` branch on Bitbucket like they create any other branch.

Hi all - not sure if there is some confusion here around how the branch targeting for Branch Restrictions works.

The example given on this ticket applies the branch restrictions "nobody is allowed to push directly to this branch" and "everyone must merge to this branch via a PR" to the `hotfix-*` branch pattern, NOT just the `hotfix` branch itself.

If I understand the requirement correctly, what you should be doing is:

1. Create that same branch restriction, but apply it only to the base `hotfix` branch, assuming that this branch is where you do things like cut hotfix releases from for example.
   1. This will prevent anyone from creating a branch called `hotfix`, and will also prevent anyone from pushing code directly to the `hotfix` branch.
   2. It will, however, give people access to merge into `hotfix` from another branch via a PR - the rules for which you can apply using Merge Checks.
2. When needing to create a hotfix, you would make changes on a branch called something like `hotfix-1234`.
   1. This would work fine because the branch restriction created previously were applied to the `hotfix` branch, not all branches starting with the `hotfix-*` prefix.
   2. You would then make your required changes on that branch.
3. Finally, when you want to get those changes into `hotfix`, you would need to create a PR from your `hotfix-1234` branch pointed at `hotfix`.
   1. This is required because `hotfix` cannot be pushed to directly, it can only be merged to via PR.
   2. This PR will then enforce whatever rules/policies you have using classic/custom merge checks.
4. Finally, once that PR is approved and all checks are passed, you would be able to merge that PR from`hotfix-1234` into `hotfix`.

I've just run through this flow E2E myself before posting this, and it works exactly as would be expected. Apologies if I've misunderstood the requirement on this, please feel free to point out if that's the case.

If you wanted to add extra structure around this, you could also do something like writing a basic custom merge check that enforces rules like:

• "All PR's being merged into `hotfix` must have a source branch that matches the `hotfix-*` pattern."
• or "Any PR with a source branch matching the `hotfix-*` pattern can ONLY be merged into the root `hotfix` branch"

This is making things difficult when setting branch permission. The fact that I am restricted from pushing or merging to a particular branch type should not prevent me from creating such a branch type. This permission has to be split in two. I have added my vote to the issue.

It is indeed very nasty bug. We have created a workaround, the Jenkins user in Bitbucket is allowed to directly commit to release/* branch as the release plugin needs this permission. Now we have an additional job in Jenkins to create a release branch. Using the release plugin, it also properly sets the version in the pom:

release:branch -DbranchName=release/${RELEASE_VERSION} -DreleaseVersion=${RELEASE_VERSION}.0-SNAPSHOT -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true -DremoteTagging=false -DsuppressCommitBeforeBranch=false

Although it is another job in Jenkins, it does make the creation of a release branch a bit easier, as you don't have to adjust pom manually.

It turns part of the branch restrictions quite useless. Just added my vote.

I voted as well. Ridiculous that this has been open for 6 years, but typical Atlassian. 

I am voting for this as well. thanks

Adding my vote as well. This is very error-prone to work around.

As people have mentioned above this is a must feature for a functioning workflow. Please address this issue! Thanks