<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=556561) </details> <!--IssueSummary end--> <!--This template is a great use for issues that are feature::additions or technical tasks for larger issues.--> ### Problem A large Ultimate, Self-Managed customer reported the following issue: Currently, GitLab's branch protection settings allow Maintainers to bypass protection rules for initial commits to new repositories. This creates a security compliance gap where: * Initial commits can bypass branch protection rules, code review processes, and security policies * Organizations cannot enforce consistent security frameworks from the first commit * Compliance requirements for regulated industries cannot be met when initial commits bypass established workflows * Security policies applied to protected branches don't apply to the most critical initial setup phase ### Proposal Add a new branch protection option (could be called: "Fully protected including initial commits") to prevent users with Maintainer role from making initial commits to new projects, requiring all initial code to go through merge requests and branch protection workflows. ### Behavior Definition When "Fully protected including initial commits" is selected: * No user, regardless of role (Developer, Maintainer, or Owner), can push directly to the default branch * All commits, including initial commits, must go through merge requests * Branch protection rules apply from the moment of repository creation * Code review, approval workflows, and security policies are enforced for all commits <!--Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues.--> <!--Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section.--> <!--Label reminders Use the following resources to find the appropriate labels: - Use only one tier label choosing the lowest tier this is intended for - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/-->