### Problem to solve As a project maintainer I see a lot of MRs created from forked projects from branches named like `patch-1`, `my-patch` or even directly from `master`. While for some projects this is probably fine, I'd prefer to prevent such branches from being used. This makes the history review really hard, because when going through Git log, all I see is the `Merged 'master' into 'master'` or `Merged 'patch-1' into 'master'` commit subjects. It lacks a lot of context. The biggest problem is that it's impossible to find out what's happening on the main branch or quickly find when a certain change was merged without looking into details of the merge commit. So I'd like to have a mechanism in GitLab that would prevent a creation of the MR, giving the author a clear explanation, basing on some per-project defined rules. For example: checking against a list of disallowed branch name patterns. I could of course add a CI task that would fail if a specific branch name would be used. But since we can't change the source branch - only the target - finding such case after the MR is created brings more additional work. The user must close the MR (or the maintainer must find all MRs in that state and close them - even worse), then push a new branch, open a new MR filling again the description, adding wanted labels etc. It would be much easier if such check could be done before the MR is created, when one can simply push the changes under a new branch and change the source in MR form. During a discussion on Slack the [Push Rules](https://docs.gitlab.com/ee/push_rules/push_rules.html) feature was mentioned as a potential solution for the problem. However, the rules can be defined only for pushed done directly to the project. This would work to prevent unwanted branch names within project team members. But it would not work for MRs coming from forks from non-team members. And this is the case that I find most problematic :slight_smile: ### Intended users * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> ### Proposal We create a concept of "Merge Request rules". At first iteration we allow to implement a list of allowed and/or disallowed patterns for the source and target branch name. The rules are maintained in Project settings, similarly to how we define Push Rules currently. When such rules are defined, the Merge Request is validated before it's being saved. If any of the rules is not fulfilled - for example the source branch is set to `master` when the rule disallows it - the Merge Request creation form fails validation and prints a clear message to the user which rule was violated. ### Permissions and Security The definition of rules should be defined similarly to how Push Rules are defined. This means it would require a Maintainer and above permission within the project/group. ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. --> ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ### What is the type of buyer? <!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> ### Links / references Related to https://gitlab.com/gitlab-org/gitlab/-/issues/8531