Rule to prevent merges >x commits behind target
Problem to solve
In general, even though a feature branch is several commits behind from
HEAD, it's unlikely to break a pipeline. But, if it's 100 commits behind, it would, if it's 1000 commits, the chance of breaking pipeline will significantly increase. In addition, we don't have a safe mechanism to check how old master the feature branch is based on. I'd still suggest to take the advantage ourselves, it's simply valuable functionality.
- Delaney, Development Team Lead, https://design.gitlab.com/research/personas#persona-delaney
Delaney wants to keep the downstream branch working so having a policy to prevent merges that need to be tested with a rebase (even if they technically merge) would be helpful.
This will also help keep master green in relation with #7380 (closed)
What does success look like, and how can we measure that?
What is the type of buyer?
Individual Contributors (Core)