Auto-rebase when merging merge request
Resources
PM @victorwu | BE @smcgivern | UX @pedroms | FE @mikegreiling
Problem
We want to continue reducing friction and abstract away git details for developers as they collaborate on code, so that their focus is on their actual work, and not the overhead of tools and git minutiae. In the merge request workflow, rebasing may be necessary before merging for two merge request methods (merge commit with semi-linear history
and fast-forward merge
) (https://gitlab.com/gitlab-org/gitlab-ee/issues/411). In particular, currently users can click a button to rebase (if the system detects it's necessary), before the merge button is displayed.
If you click the button, the system attempts to rebase for you, and if successful, the merge button is shown. There are two steps here that can be combined into one, because computers are good at automating things.
Solution
- For the two merge request methods (
merge commit with semi-linear history
andfast-forward merge
), offer the ability to rebase and merge in a single action. - Note: For below,
strikethroughindicates existing functionality that will be removed and bold indicates new functionality.
- No pipeline exists (No GitLab CI set up)
- MR needs a rebase
- MR is non-rebaseable
Merge button, and an error after clicking the button- Access to source branch: Rebase locally button that shows instructions (button; instructions modal) If rebase succeeds, show message “Ready to be merged automatically. Ask someone with write access to this repository to merge this request.”
- No access to source branch: No buttons, only message to ask MR author to rebase locally (message)
- MR is rebaseable
- Access to only source branch: Rebase button (rebase) If rebase succeeds, show message “Ready to be merged automatically. Ask someone with write access to this repository to merge this request.”
- Access to source AND target branch: Merge and Rebase only buttons. Merge will auto-rebase+merge immediately. (merge or rebase only) If Rebase only, after it succeeds, show Merge button.
- No access to source branch: No buttons, only message to ask MR author to rebase (message)
- MR is non-rebaseable
- MR does not need a rebase
- Merge button
- Pipeline running
- MR needs a rebase
- MR is non-rebaseable
Merge button, and an error after clicking the button- Access to source branch: Rebase locally button that shows instructions (button; instructions modal) If rebase succeeds, show message “Ready to be merged automatically. Ask someone with write access to this repository to merge this request.”
- No access to source branch: No buttons, only message to ask MR author to rebase locally (message)
- MR is rebaseable
- Access to only source branch: Rebase button (rebase) If rebase succeeds, show message “Ready to be merged automatically. Ask someone with write access to this repository to merge this request.”
- Access to source AND target branch: Merge (blue button) and Rebase only buttons. Merge will auto-rebase+merge immediately. (merge or rebase only) If Rebase only, after it succeeds, show Merge (blue) and Merge when pipeline succeeds (orange) buttons.
- No access to source branch: No buttons, only message to ask MR author to rebase (message)
- Not in scope: Merge when pipeline succeeds button (blue) that will auto-rebase+merge when pipeline succeeds
- MR is non-rebaseable
- MR does not need a rebase
- Merge when pipeline succeeds button (blue)
- Merge button (orange) to merge immediately
- Pipeline passed
- Same as 1. No pipeline exists, above
- Pipeline failed
- Pending discussion
Original description (with some images removed to save space)
Original description
We have different Merge Request merge strategies:
- Merge commit
- Merge commit with semi-linear history
- Fast-forward merge
At the moment we have two issues on GitLab about the last two merge strategies.
1. First problem: rebase before merging
As @dblessing pointed out, in most cases we need to rebase before merging. This leads to the screenshot below, where we need to rebase before being able to merge. Users shouldn’t have to always click on Rebase, then Merge. There is one useless action here.
2. Second problem: voting on a merge requests
The second problem comes with our approval feature, i.e. when a MR requires votes to be merged. At the moment, if the MR has been approved and a rebase occurs after that, the approvals are reset and people have to approve the MR again. It’s unnecessary.
Specification
Our goal with this feature is to simplify the merging process.
- Change the flow for Merging a MR in the case where the project’s merging strategy is set to either Merge commit with semi-linear history or Fast-forward merge:
- If we detect that a rebase is necessary when the page loads, we should mention that we will rebase automatically before merging once the Accept Merge Request button is clicked.
- Rebase should happen behind the scene automatically after we click on the Merge button.
- If an error occurs during rebase, we go through our new Resolve merge conflicts feature.
- If there are no errors during rebase, we apply the merge and go through the normal flow after that.
- Approval strategy. If the MR has an approval strategy in place:
- Same as now: it’s still not possible to click on the Accept Merge Request button if the number of approvals necessary for merging is not reached.
- Same as now: if a user rebases from the CLI and pushes the changes to the MR, we should reset the approvals.
- Different from now: in the UI, when clicking on the Accept Merge Request button, if a rebase is necessary, this rebasing should not reset the approvals.
The old flow was: Approvals → Click on Rebase → Approvals again → Click on Merge → MR merged.
The new flow is: Approvals → Click on Merge → (Automatic rebase, then Merge operation behind the scenes) → MR merged.
Documentation
Once this feature will be done, we need to update the documentation: https://docs.gitlab.com/ee/workflow/rebase_before_merge.html
References
- Part of issue #411 (closed) (Improve Merge Request accept flow with automatic rebase and option to squash)
- Prerequisite for #150 (closed) (Provide Squash option when merging MRs)
- Should close https://gitlab.com/gitlab-org/gitlab-ee/issues/895
Pinging @DouweM and @JobV for technical feasibility and approval.