From 05f0b04ead19be78fe6a007e7993490a552c28fe Mon Sep 17 00:00:00 2001
From: Patrick Cyiza <jpcyiza@gitlab.com>
Date: Thu, 23 Feb 2023 21:31:19 +0000
Subject: [PATCH] Resolve linting issues in contribution
Fix future tense by changing it to present tense. Leave all other
edits for a separate commit.
---
doc/user/project/protected_branches.md | 37 ++++++++++++++++++++++++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/doc/user/project/protected_branches.md b/doc/user/project/protected_branches.md
index da53fe2f5e92..bbef12cd0e12 100644
--- a/doc/user/project/protected_branches.md
+++ b/doc/user/project/protected_branches.md
@@ -36,6 +36,40 @@ When a branch is protected, the default behavior enforces these restrictions on
1. No one can delete a protected branch using Git commands, however, users with at least Maintainer
role can [delete a protected branch from the UI or API](#delete-a-protected-branch).
+### When a branch matches multiple rules
+
+When a branch matches multiple rules, the **most permissive rule** determines the
+level of protection for the branch. For example, consider these rules, which include
+[wildcards](#configure-multiple-protected-branches-by-using-a-wildcard):
+
+| Branch name pattern | Allowed to merge | Allowed to push |
+|---------------------|------------------------|-----------------|
+| `v1.x` | Maintainer | Maintainer |
+| `v1.*` | Maintainer + Developer | Maintainer |
+| `v*` | No one | No one |
+
+A branch named `v1.x` matches all three branch name patterns: `v1.x`, `v1.*`, and `v*`.
+As the most permissive option determines the behavior, the resulting permissions for branch `v1.x` are:
+
+- **Allowed to merge:** Of the three settings, `Maintainer + Developer` is most permissive,
+ and controls branch behavior as a result. Even though the branch also matched `v1.x` and `v*`
+ (which each have stricter permissions), users with the Developer role can merge into the branch.
+- **Allowed to push:** Of the three settings, `Maintainer` is the most permissive, and controls
+ branch behavior as a result. Even though branches matching `v*` are set to `No one`, branches
+ that _also_ match `v1.x` or `v1.*` receive the more permissive `Maintainer` permission.
+
+To be certain that a rule controls the behavior of a branch,
+_all_ other patterns that match must apply less or equally permissive rules.
+
+If you want to ensure that `No one` is allowed to push to branch `v1.x`, every pattern
+that matches `v1.x` must set `Allowed to push` to `No one`, like this:
+
+| Branch name pattern | Allowed to merge | Allowed to push |
+|---------------------|------------------------|-----------------|
+| `v1.x` | Maintainer | No one |
+| `v1.*` | Maintainer + Developer | No one |
+| `v*` | No one | No one |
+
### Set the default branch protection level
Administrators can set a default branch protection level in the
@@ -203,8 +237,7 @@ Members who can push to this branch can now also force push.
## Require Code Owner approval on a protected branch **(PREMIUM)**
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/13251) in GitLab 12.4.
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35097) in GitLab 13.5, users and groups who can push to protected branches do not have to use a merge request to merge their feature branches. This means they can skip merge request approval rules.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35097) in GitLab 13.5, users and groups who can push to protected branches do not have to use a merge request to merge their feature branches. This means they can skip merge request approval rules.
For a protected branch, you can require at least one approval by a [Code Owner](code_owners.md).
--
GitLab