Vision for Branch rules

Branch rules was started because we wanted to proceed down the path of making settings branch centric rather than feature focused.

What that means that instead of going to "Settings > Repository > Protected branches" to configure your branch protections then going to "Settings > Merge requests > Merge request approvals" to define the rules, you would go to one place "Branch rules" to configure both in the same place.

We started with these epics

• MVC: Branch Rules Overview (&8578 - closed)
  • Exploring the layout of having settings displayed branch centric.
• [MVC] Branch Rules Editing (&8075 - closed)
  • Allow creation and updating of branch rules

But what is next after this? Some ideas here &12494 but this is an opportunity to look at what can be done.

Past evidence

From https://gitlab.com/gitlab-org/ux-research/-/issues/1644#finding-and-outcome

• Users described the nature of the branch (main, feature, bug fix, ect) as a determining factor for deciding what permissions should be applied.
• Users described having a different set of rules that they would apply to the main branch. All participants stated a more restrictive set of permissions compared to other branches.
• Any organizational system would need to make special consideration for the main branch
• When asking participants about how they related branches and rules, while their strategies varied, all participants seemed to accept that branches drive rules.
• Users indicating positive experiences using SCM systems that have a branch first organizational structure.
• The correlation is likely do to the nature of branches as a development strategy and therefore make sense as organization system for rules.

Future looking

Reorganization of existing settings into branch rules

We have identified some recent settings that could fall under the area of "branch rules"

• Change default target branch for merge requests (#17909 - closed)
• Merge Request Squash Settings per protected bra... (#290042 - closed)

Improve visibility of rules for a branch

Settings for a branch is one thing but understanding what has been configured for a branch is opaque at the moment in GitLab. Things that could be explored is a read-only view of rules for a branch and better visibility/summaries to better understand what has been set for a branch.

• Display summary of resolved branch rules for a ... (#393142 - closed)

Rules expression

Expansion of the concept of rules is to looking into how they can be combined: branch rules + push rules to allow for expressive settings to adapt to more workflows.

• Branch-specific Push Rules (#32108)

Concerns moving forward

• API parity of what's available today versus what's available for branch rules
• Are there faster ways to get to an MVC faster by limiting settings to be applied to protected branches as that is what most settings use as a target.