Developer cannot push to projects they create in groups

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
2. 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.

Original Proposal

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.

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