Cascading merge requests into multiple branches
Problem to solve
When fixing a bug, the fix frequently needs to be applied to multiple stable branches like
stable-12-0. Applying the fix to multiple locations is time consuming requiring multiple merge requests to be created manually.
This is common workflow and GitLab should provide a simple and automated workflow.
Unlike the proposal in #2785 (closed), the solution should address the workflow where the fix is first merged into the default branch, which is the single source of truth. Once the change is merged into default branch it has been reviewed and approved.
Subsequent merge requests merging the change elsewhere should use this reviewed and approved change as the source of truth.
This can likely build off the work in #9688 for relating merge requests across projects, however there is an important difference:
- merge at once, and ordered merge solves the problem of merge requests existing at the same time
- a cascading merge would create one after the other
A cascading merge is preferable to creating all the merge requests at the same time because then there is no single source of truth. If a change is requested on the merge request to the default branch, every other branch needs to be updated. Worse still, what if changes were requested on different merge requests - this might be important for version specific considerations, but it would be easy for this to devolve into a code review spread across an arbitrary number of branches and merge request
Merge requests (MR) can only be created from one source branch to one target branch. If you enforce "create merge request to merge your branch" via "push: none" the standard hotfix workflow (create hotfix branch from master, fix problem, merge into master and develop) can not be applied.
A workaround would be to create two MR: one into master, another one into develop. But this does not work when "Remove source branch" is checked (which we set as the default). If you merge one of the two merge requests, Gitlab does not check for other MRs and will just delete the source branch which results in the following error on the second MR (feature/foo would actually be hotfix/foo).
After merging a change into the default branch
master, the merge request will provide show a new option to Backport to
|Mockup showing backport button|
This will create a new merge request backporting the change. The change can be backported in this way one stable branch to the next.
As the merge request is backported, the original merge request will show related merge requests, linking to the backported changes.
|Mockup showing backport merge requests yet to be created|
A further iteration could allow the author of the first merge request to specify the ultimate target semver branch before the first merge request is even merged, so that the creation of all the merge requests is automatic.
- is anyone automatically assigned to the merge request?
- what approval rules apply to the merge request? #460