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

@@ -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).