breadcrumbs: How-Tos > page_name: drover title: How to merge a change to a release branch
Please read the Merge Request Process and The Zen of Merge Requests for more details on when we merge changes to release branches, and how to request a merge.
This document assumes you‘ve already landed your change on the master branch, you’ve already requested a merge (via the Merge-Request-XX label, where XX is the milestone), and you've already received approval to merge onto a particular release branch from a TPM (via the Merge-Approved-XX label).
Merging to a branch and don‘t know the branch number? The TPM (release manager) approving the merge will have it, and it’s typically sent out in an email after every branch.
Once you have approval, you know your branch number, and you're ready to merge there are two ways to merge a change.
(1) The easiest way: using Gerrit to cherry-pick CLs
You can use Gerrit to cherry-pick CLs directly to our release branches where no conflicts are present (if there are merge conflicts, use the manual way instructions below), no terminal required! To do so, follow the steps below once you have merge approval:
Press the “More” button and select “Cherry Pick”
Enter branch details. For Chromium, use refs/branch-heads/####:
Voila, you now have a fresh CL uploaded for the branch. Simply add Rubber Stamper (rubber-stamper@appspot.gserviceaccount.com) as a reviewer and set Auto-Submit+1, the Rubber Stamper bot will approve and submit the CL to CQ on your behalf. Note: The Rubber Stamper does not provide OWNERS approval, and only works within 7 days of the original change; Googlers can learn more at http://go/rubber-stamper-user-guide.
NOTE: non-committers will need a CR+1 and CQ+2 from a committer to complete the merge.
After merging to a release branch, try to watch http://go/stablebuilders (for stable branches) and http://go/betabuilders (for beta branches) and here for dev/trunk branches to make sure everything's all right.
If a minor change needs to be made to the CL (e.g. missing include), it's possible to make the change directly via the Gerrit edit function after the merge has been created. See Gerrit instructions here:
https://gerrit-review.googlesource.com/Documentation/user-inline-edit.html
You will need review approval as use of TBR is being discontinued.
Important: You must click “Publish Edit” after making the changes, for your edit to show up as an actual patchset that can be submitted to the CQ.
This isn't any harder; it can just take longer because you have to check out the whole release branch. This can be a good approach if your patch has a lot of merge conflicts or you have to deal with file renames, or if you just need to check out the release branch in order to compile and test your change because the merge was tricky.
The first step is to make sure that you have branch heads:
$ gclient sync --with_branch_heads
Also ensure that your git repository is up-to-date:
$ git fetch
Now, create a new branch from the top of the branch-head (consider using multiple working directories to avoid switching branches on your main checkout). Replace my_branch_name with a name for the branch, and BRANCH with the branch number you got from the TPM (see above).
$ git checkout -b my_branch_name refs/remotes/branch-heads/BRANCH
You will also need to set the upstream branch to point to the release branch, otherwise `git cl upload` would build a delta by default from origin/main and bundle many commits erroneously.
$ git cl upstream branch-heads/BRANCH (Note the lack of `refs/remotes/`)
Next, cherry-pick the change you want to land, using the hash of the commit you want to pick from the master branch:
$ git cherry-pick -x HASH_OF_THE_COMMIT_FROM_MASTER
At this point, resolve any conflicts if necessary, and use git cherry-pick --continue if prompted to do so. Optionally run “gclient sync” and use ninja to build and test to make sure your patch worked. Make sure to remove the “Change-Id: ...” line from the commit message before uploading.
Now upload the change for review. You should edit the change description to say something like “Merge to release branch” at the top or something like that, to make it easier for your reviewers to distinguish this change from the original patch. You will need review approval as use of TBR is being discontinued.
$ git cl upload
If this fails with the following error message, it is due to the presence of a Change-Id in the commit log:
! [remote rejected] .... (change https://chromium-review.googlesource.com/99999 closed)
This can be solved by removing the entire line of “Change-Id: ...” field in the commit log. Gerrit will bypass the checking on “Change-Id” and will let you submit the cherry-pick CL.
You can now use Gerrit to complete the review and send the CL to the CQ for submission.
