Add "maximum commits behind" check before merge

Problem to solve

Merging into a branch comes with certain risks, depending on how out of date the source branch is vs. the target. For a simple example, someone in the target branch may have removed a dependency that the source branch still needs. There's no merge conflict so the merge can go through, but there's a semantic problem that will result in everything not working.

We are addressing more advanced strategies for these kinds of pipelines by https://gitlab.com/gitlab-org/gitlab-ee/issues/9186, but a basic and easy to understand mitigation strategy could help immediately and allow more teams to immediately adopt https://gitlab.com/gitlab-org/gitlab-ee/issues/7380.

Target audience

Further details

This would be further improved with automatic or scheduled rebasing.

Proposal

Without having to analyze and understand interdependencies of everything in the project, we can help mitigate this by setting a maximum difference between the source and target branch in terms of number of commits. An elegant way to do this is to take the average number of commits per day (looking at a one month period) in the project and disallow merges that are > than that value behind. This helps in a couple different scenarios. Imagine a project with 25 commits per day:

  • On an average day with about 25 commits happening, you can be about a day behind and there is no issue. You will only be prompted to rebase when you want to merge and are more than a day behind.
  • In a "code freeze" situation where 75 commits are happening in a day, the risk is much higher that all of the things coming in will have semantic incompatibilities with each other. By using the average commits per day value, we automatically scale the number of rebases needed on that day in order to keep things more likely to succeed.

What does success look like, and how can we measure that?

TBD

What is the type of buyer?

Individual Contributor

Links / references

Edited by Jason Yavorsky