... | ... | @@ -4,7 +4,7 @@ |
|
|
|
|
|
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`:
|
|
|
|
|
|
* 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`.
|
|
|
* 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:
|
|
|
|
|
|
```
|
... | ... | @@ -24,7 +24,7 @@ There are two scripts that can make this process more convenient: |
|
|
So for the example above you might run:
|
|
|
|
|
|
```
|
|
|
sh util/git-replay-merge.sh <merge_commit_id> origin 9999-short-description-v9_16
|
|
|
sh util/git-replay-merge.sh <merge_commit_id> origin v9_16
|
|
|
```
|
|
|
|
|
|
2. GitLab also has a "Cherry-pick Merge Request" button. If commits apply cleanly this is perhaps the most intuitive workflow.
|
... | ... | |