### Summary The [branches API](https://docs.gitlab.com/ce/api/branches.html) allows branches to be listed, created, deleted, protected and unprotected via API calls. Unfortunately, the functionality for protecting branches over the API is not as sophisticated as that of the web UI. Simply, via the API, it's only possible to configure whether users of role `Developer` can push/merge to protected branches, while via the Web UI it's possible to configure whether `No-one`, `Masters` or `Masters + Developers` can push or merge respectively. The bug is that if you've set up that `No-one` should be able to push to a protected branch via the web UI, then attempt to configure the branch protection via the API, setting `developers_can_push` to false, it'll turn ON push permissions for `Masters`. Same thing for merge permissions obviously. This means that branch protection cannot be reliably configured via the API for users who desire `No one` to have push access to protected branches. This is present in both v3 and v4 versions of the API. ### Steps to reproduce 1. Create a new protected branch via the web UI. Set push permissions to `No one`. 2. Attempt to protect the branch [via the API call](https://docs.gitlab.com/ce/api/branches.html#protect-repository-branch). Set `developers_can_push` to `false`. 3. The push permission setting is now `Masters`. ### What is the current *bug* behavior? Setting `developers_can_push` to `false` sets `Masters` to push permission on protected branches. ### What is the expected *correct* behavior? Ideally I would like the same granularity in the API as there is over the web UI, but even without that, setting `developers_can_push` to `false` should NOT set the push permissions to `Masters`. ### Output of checks This bug happened on a githost.io instance running Gitlab 9.0.