### Summary When a group allows developers to create new projects, the developer is unable to push any code without the `Maintainer` permission, but it is not desirable for a developer to receive elevated permissions. The `master` branch is protected by default when creating a new project, which prevents the developer from pushing to that branch without the involvement of a `Maintainer`. This workflow is disruptive and does not provide the expected experience for users. ### Steps to reproduce 1. In a group where you only have developer permissions, create a project 1. Check the members page to see your permissions and try to push to the `master` branch ### What is the current *bug* behavior? I only have **Developer** permissions on the project I created and cannot push to the `master` (default protected) branch. ### What is the expected *correct* behavior? As a `Developer`, I should be able to push to the project I've just created without intervention from a `Maintainer`. ### Use Case As a `Group Owner`, I want `Developers` to be able to push code to new projects they create and allow `Owners` and `Maintainers` to protect the branch after the initial code has been pushed. ### Proposal Bring `default branch protection` settings to the group-level to allow flexibility in defining expected behaviors for `project creation` and `pushing commits`. | Figure 1 | | ------ | |  | | Instance-level setting for `default branch protection` | ### Additional information The possible configurations would be possible in this move: | **Default branch protection** | **Default project creation protection** | **Create Projects** | **Push new commits** | **Benefit** | | ------ | ------ | ------ | ------ | ------ | | Fully protected | Maintainers | Maintainers | Maintainers | Maintainers retain strict control of the group and must be involved with project initialization. | | Partially protected | Maintainers | Maintainers | Maintainers + Developers | Maintainers control project creation to limit volume, but Developers can still push new commits to these new projects. | | Partially protected | Maintainers + Developers | Maintainers + Developers | Maintainers + Developers | Both Maintainers and Developers can create projects and push new commits. | `Maintainers` can still visit each project created by a `Developer` to modify the default protected branch setting **Allowed to push** from `Maintainers + Developers` -> `Maintainers` after a project has been initialized. These settings could allow developers to create projects and initialize them **without involving a maintainer**. This provides some flexibility to group owners to alleviate friction for `Developers`. More work is required to address the multiple use cases represented in this issue. <details> <summary>Original Proposal</summary> 1. A new setting on the project creation screen to (optionally) protect the `master` branch. (default: checked/enabled) - **Figure 1** 1. If enabled, only `Maintainers` can push code and workflows remain unchanged 1. If disabled, the default protected branch is created with the settings in **Figure 2**. Both `Maintainers` and `Developers` can push code to `master` for this project only. 1. Once a project has been setup, an `Owner` or `Maintainer` can modify the project settings to `Protect` the master branch by changing the protected branch settings to `Maintainer` only. - **Figure 3** **Workflow** | Figure 1 | Figure 2 | Figure 3 | | ------ | ------ | ------ | |  |  |  | | Any `User` who can create a project, can (optionally) protect `master` on new projects. | The default protected branch, when initialized, will allow `Maintainers + Developers` to push and merge code into the default protected branch. | `Owners` and `Maintainers` would be able to modify `Protected Branches` in the project settings to secure the project once initial code has been pushed by a `Developer`. | </details> <!-- | New Group level setting | Create Project | Maintainer View | Developer View | | ------ | ------ | ------ | ------ | |  |  |  |  | | A `Group Owner` will allow or disallow optional branch protection in `Group Settings`. | A `User`, with permission to create projects, creates a new `Project` in their group. | The `Project` creation UI presents a checkbox to optionally protect (or not) the default branch. | If a `Developer` creates the `Project`, the checkbox is visible but inactive. | --> Some thought will be required on managing the compliance aspect of this workflow. While it is desirable to enable developers to push to the projects they've created, it may be necessary to at least notify `Owners` or `Administrators` when an unprotected branch is created. Additionally, there may be a need to implement a group-level setting (or another mechanism) to "require all new projects protect master branch" to provide controls for organizations to maintain compliance status, which would override the solution proposed here. This could manifest elsewhere as a report showing a list of unprotected branches, but this is likely a separate issue for consideration. ### Output of checks This bug happens on GitLab.com