Summary

This document explains why it is not possible to  completely override the branch restriction set at the project level for a specific repository.

Diagnosis

This issue occurs because in Bitbucket Cloud, merge checks and branch restrictions are not hierarchical; rather, they apply whichever is the most restrictive. 

Example 1

As an example, let us take a project which has the merge check - A user "Alana" has access to write to master and nobody else. 

At the repository level, we add a merge check that everybody has access to write to master by choosing "Everyone with access to the repository has merge access" option. Since Alana is more restrictive than the Repository Level Setting, it is enforced and the Project level merge check will take precedence over the repository level merge check. More details on how the restrictiveness of a check is evaluated can be can be found in our documentation. 

Example 2

For this example, consider a project which has the following merge check - Minimum number of successful builds for the last commit with no failed builds and no in progress builds. If the value is 1, that means every pull request in every repository of the project must have at least one successful build before it can be merged. 

Let us consider a use-case where a specific repository does not need this requirement because they do not use Pipelines - i.e. You want pull requests of this repository to not have this check and allow merging if there or no successful builds or no builds at all. Unchecking the merge check from Repository Settings will not succeed in this case since repository level settings do not blindly override the project level settings. Rather, we evaluate which is the most restrictive and apply that. In this case, having 1 successful build is more restrictive than having no builds and hence, the check will still apply despite disabling this check at the repository level. 

Solution

If you have certain repositories that require more lax requirements than the rest of the project, you must put the least restrictive check at the project level and enable stricter checks at the repository level. In the above example, disabling the check at the project level and enabling it repository by repository from Repository Settings would resolve the issue and ensure that the repository which does not use Pipelines can still merge it's pull requests.