...
There are few different scenarios here, and few different moving parts. Once you get the hang of it, though, this should feel like a quick & easy process.
| Table of Contents | ||||
|---|---|---|---|---|
|
Making a change that also belongs on master (a “backport”)
For newer repositories, substitute master for main. However, the named release branch is still called open-release/XXX.master in every repository.
...
top-level repository, signified by the presence of a open-release/XXX.master named release branch; or a
library repository, which is installed into the release by Pip or NPM and thus doesn’t have a named release branch.
Backporting to a top-level repository
| Info |
|---|
This is the most common workflow. |
Ensure the change is already merged to master.
Find the commit hash(es) of the fix you need from master. They might be the same as in the fix pull request you are copying from, or they may be different if the pull request was closed with a squash. The best thing to do is to update your master branch, and get the hashes shown in your local git log:
$ git logCheck out the release branch:
$ git checkout open-release/XXX.master$ git pullMake a new branch from the release:
$ git switch -c <YOURNAME>/<BRANCHNAME>Cherry-pick the commits onto your branch. Do this for all your commits:
$ git cherry-pick -x <COMMITHASH> ...Push your branch:
$ git push -u origin HEADMake a pull request from your branch, using open-release/XXX.master as the base. In your pull request description, mention the original pull request on master that you are copying, if you can.
Tag people for review. The pull request will be handled and merged like any other.
Backporting to a library repository
| Note |
|---|
This can seem complicated the first time you do it. Reach out to #wg-build-test-release if you need help! |
...