... | ... | @@ -2,10 +2,36 @@ |
|
|
|
|
|
## Introduction
|
|
|
|
|
|
When a merge request is merged into *master*, it may need to be backported to maintenance branches. As each merge request consists of multiple commits, backporting it to another branch without squashing boils down to:
|
|
|
When a merge request is merged into *main*, it may need to be backported to maintenance branches. As each merge request consists of multiple commits, backporting it to another branch boils down to using `git cherry-pick`:
|
|
|
|
|
|
* cherry-picking the original commits comprising the merge request one-by-one on top of the target branch (i.e. the branch to which the merge request is being backported),
|
|
|
* creating a merge commit linking the previous HEAD of the target branch with the last cherry-picked commit, preferably retaining the commit log message from the original merge commit (e.g. to leave the merge request identifier intact for future reference).
|
|
|
* Create a new branch to be merged into the release branch. For example, if you are working on a GitLab issue number 9999 for version 9.16, you could create `9999-short-description- v9_16`.
|
|
|
* Cherry-pick each commit from the original merge request:
|
|
|
|
|
|
```
|
|
|
git cherry-pick -x <commit>
|
|
|
```
|
|
|
* Some commits won't apply cleanly, fix the commits manually.
|
|
|
* Creating a merge commit linking the previous HEAD of the target branch with the last cherry-picked commit, preferably retaining the commit log message from the original merge commit (e.g. to leave the merge request identifier intact for future reference).
|
|
|
|
|
|
There are two scripts that can make this process more convenient:
|
|
|
|
|
|
1. `git-replay-merge.sh` is a scripted version of the previous workflow. The script can be found in the repository. If it works for you, you can run:
|
|
|
|
|
|
```
|
|
|
sh util/git-replay-merge.sh <merge_commit_id> <target_remote> <target_branch>
|
|
|
```
|
|
|
|
|
|
So for the example above you might run:
|
|
|
|
|
|
```
|
|
|
sh util/git-replay-merge.sh <merge_commit_id> origin 9999-short-description-v9_16
|
|
|
```
|
|
|
|
|
|
2. GitLab also has a "Cherry-pick Merge Request" button. If commits apply cleanly this is perhaps the most intuitive workflow.
|
|
|
|
|
|
### Backporting a merge request to a subscription release
|
|
|
|
|
|
Backporting to a subscription release is slightly different. Basically, we squash the merge request into single commit and then merge it into the subscription release branch. The reason for squashing is that it becomes quite a mess after a while when continuously rebasing stuff on top of the regular release branch.
|
|
|
|
|
|
## `git-replay-merge.sh` to the rescue
|
|
|
|
... | ... | |