Configure repository merge strategy
Problem to solve
Some organizations need to have finer-grained control over which merge strategy is to be used for each of its repositories. (e.g. only allow squash-merge instead of rebasing or merging).
Intended users
- Rachel (Release Manager)
- Delaney (Development Team Lead)
- Sasha (Software Developer)
- Devon (DevOps Engineer)
- Sidney (Systems Administrator)
Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ -->
Further details
On Github, organizations have used a similar feature to ensure all merges are consistently done the same way. Squash-merge only repos are particularly useful for tracking changes and reverting when necessary (as there's less noise compared to commit-merge). On Gitlab, we depend on "guidelines" alone and having individual contributors with merge access to remember to follow the organization-specified procedures. By having that as a configurable option, we can take that cognitive burden out of mergers and ensure consistency.
Proposal
We would add an extra option to the repo configurations containing the merge strategies supported by Gitlab and allow users to toggle the ones allowed. The merge-request UI, API and processing mechanisms would, in turn, adapt to conform with the choice. If only one option would've been picked, merging would automatically default to it.
Permissions and Security
The permission level needed for changing this setting on the repo would be the same for configuring any other option. As for enforcing the selected merge-strategy, that would've to be reflected on the UI and any other entry points that would cause a merge to happen.
Documentation
To-be-included based on the receptiveness of this proposal.
Availability & Testing
What does success look like, and how can we measure that?
Success can be defined by having a to be established threshold of organizations actively using the feature, meaning there are plausible reasons for us to increase complexity by having an extra configuration option.
The acceptance criteria for this feature can be defined as per the following user story: "As a repository administrator, I want to be able to select a single merge-strategy and have all future merges be done automatically using the selected strategy."
What is the type of buyer?
Unclear. This kind of decision is something we need to further discuss based on how GitLab intends to monetize this feature.