Cascading merge requests into multiple branches
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Problem to solve
When fixing a bug, the fix frequently needs to be applied to multiple stable branches like master, develop, stable-11-10, stable-11-11, and 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.
Further details
Unlike the proposal in https://gitlab.com/gitlab-org/gitlab-ee/issues/2785, 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 https://gitlab.com/gitlab-org/gitlab-ee/issues/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
Original proposal
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).
Proposal
After merging a change into the default branch master, the merge request will provide show a new option to Backport to release-X-Y
| 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.
Questions:
- is anyone automatically assigned to the merge request?
- what approval rules apply to the merge request? https://gitlab.com/gitlab-org/gitlab-ee/issues/460