Auto-merge between release branches
Bugs and security fixes often need to be added to multiple branches, either back porting fixes to old releases, or fixing an issue in
master and pending release branches that have already been branched. This can be done manually, but it is laborious and error prone. GitLab should make releasing fixes easy.
- When you do a production hotfix to a release branch, GitLab will attempt to auto-merge to newer release branches, and also back to the development branch.
- This will will ensure that any urgent fixes (bugs, major regressions, security patches) are merged to ongoing development work.
- For example, suppose release 1.0 is already in production and there is a major bug discovered. The team does a production hotfix to the branch and releases it. But there are already subsequent branches, 1.1, 1.2 that are currently undergoing final QA and getting ready to be deployed. Always, there is an ongoing mainline development branch. That production hotfix should be merged to those branches.
- GitLab will make the best attempt to merge that change across those branches. Whether they succeed or fail (due to a merge conflict), there will be an indication.
- The mechanism is triggered by the merge request being merged into to a release branch. Upon that merge request being merged, GitLab will make the attempts on the other subsequent branches. The results (succeed or failure) will be logged as system notes in that merge request.
- To know which are release branches and which are newer release branches, we will follow a naming convention. (In future iterations, we may consider making explicit associations. But naming conventions should suffice for now.) Use semantic versioning to indicate newer release branches. (I.e. https://semver.org). A branch is considered a release branch if it has
releasein it's name. And the main development branch is
- This is feature that is configured as a setting in the project settings.
Essentially the idea is that if I have a branch setup of
(Just pretend there are branches between release/1.1-release/1.9)
If I then make a production hotfix to release/1.0, this should then attempt to auto-merge from release/1.0 all the way to develop. It's an efficient automated way to make sure hotfixes are always added to each respective release branch. Should CI Builds fail or merge conflicts occur, these would have to be solved manually of course. The way branches merge should be customizable, not enforcing the use of git flow.