<!--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> - [Work on this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=358910) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=358910) </details> <!--IssueSummary end--> ## Context When users have a wildcard say `release-v1*` and a branch rule name `release-v1`, the most permissive rule applies and the wildcard takes precedence. This is confusing for users who expect most specific name match to take precedence over wildcards. Users have reported repeated frustration with this: * #28048+ * #26724+ * #39115+ See https://gitlab.com/gitlab-org/gitlab/-/issues/551099#note_2583242597. > I wasn’t aware we couldn’t create an exact-match name without the branch existing. I believe that is a **bug**. We should be allowing any name even if the branch does not currently exist. That’s how protected branches works. ## Design Proposal See https://gitlab.com/gitlab-org/gitlab/-/issues/551099#note_2584378221. * Add the option for users to create a branch rule with a specific name (even if the branch does not exist) * Specific branch names should take precedence over the wildcard matches. * Update the docs if needed. <table> <tr> <th>Current</th> <th>Proposed: Branch rule creation with branch name</th> </tr> <tr> <td> {width=789 height=239} Users are not allowed to create a branch rule for branches that don't exist {width=1116 height=325} Users are allowed to create branch rules with wildcards </td> <td> {width=1273 height=409} Text should say `No branches found` instead of `No results found` </td> </tr> </table> <details> <summary> ### Design questions (out-of-scope) </summary> #### How to determine which rule is best match for a branch? Keep in mind with protected branch rules there are group-level rules that would be cascading down to projects https://gitlab.com/groups/gitlab-org/-/epics/8679. From the order of least to most specific: * Wildcard matches * Group-level rules * Project-level rules * Name branches * Group-level rules * Project-level rules This pattern of presenting rules like this can be thought of as a funnel with the widest least specific rules at the top and getting narrower and more specific as you go down the list. Examples of this in use is with this comment https://gitlab.com/gitlab-org/gitlab/-/merge_requests/52319#note_512636614. To help visualize the precedence order, we would present the protected branches alphabetically in order of precedence order from least to most specific. With 3 rules `feat/1234-new`, `*`, and `feat/*` it would be presented like: * `*` (least specific) * `feat/*` * `feat/1234-new` (most specific) #### Handling duplicates A duplicate would be considered as having the exact same structure. `feat/*` & `feat/*` would be a duplicate. For example `*` & `feat/*` would have an overlap but are not duplicates. #### Feedback required: Similar rule scenario Suppose you had two rules A) `f*ture` and B) `featu*e` and you wanted to match branch `feature`, which rule would match A or B? Looking at the rules: * `A` would match names like "future", "feature", "feature/123-new-fixture". * `B` would match names like "feature", "feature/123-new-fixture". Determining the rules to resolve this scenario would apply to resolve similar real scenarios like this https://gitlab.com/gitlab-org/gitlab/-/merge_requests/52319#note_510049751 that have matching patterns of `*`, `v*.*.*`, `v*.*.*.*` These rules do not have the exact same structure so they would co-exist.When rules A and B are sorted alphabetically (A-Z), the result would be: * `f*ture` (A) * `featu*e` (B) This means rule `B` would match for branch `feature`. It would match because both are wildcards and when ordered alphabetically `B` is the last rule to match. </details> ### <details> <summary> ### Original proposal (outdated) </summary> While using gitlab protected branches with wildcards, the wildcard branch name takes precedence over a fully named branch rule. e.g. in this demo repo: https://gitlab.com/cy4n/protected-branch-demo a) i am allowed to push into branch_1, although "no one" is allowed to push.b) i am not allowed to merge into branch_1 without codeowner approval (both points showing that the wildcard branch takes precedence)  **Expected Behaviour:** the more explicit rule for branch_1 shoulda) forbid me to push as anyoneb) allow me to merge (as a maintainer) without codeowner approval </details>