gittrunk

Google's Trunk Based Development - Do you push code directly to release branch instead of trunk?

I am studying Google's trunk based development

enter image description here

In trunk-based development, developers push code directly into trunk. Changes made in the release branches—snapshots of the code when it's ready to be released—are usually merged back to trunk (depicted by the downward arrows) as soon as possible. In this approach, there are cases where bug fixes must be cherry picked and merged into releases (depicted by the upward arrow), but these cases are not as frequent as the development of new features in trunk.

It states that

changes made in the release branches—snapshots of the code when it's ready to be released—are usually merged back to trunk (depicted by the downward arrows) as soon as possible

I'm confused because right before that it states that developers push code directly into trunk.

  1. How is it that code would be pushed to a release branch if it is supposed to be pushed directly to trunk?

  2. Why would bug fixes be cherry picked and merged into release branches it's implied that bug fixes are done in a release branch and that release branch is merged to master?

  3. Assuming code is not directly pushed to a release branch, why would the release branch be merged back into master/trunk if it was forked from master?

Solution
    1. How is it that code would be pushed to a release branch if it is supposed to be pushed directly to trunk?

    The goal of a release branch is to let you focus on preparing the software for release without having to worry about what's happening in trunk. While the rest of the team keeps working towards the next version by committing directly to trunk, you stabilize the snapshot that was chosen for release by fixing any remaining bugs in the release branch.

    During this stabilization process, you may find bugs that also exist in trunk. When that happens, you'll want to merge the release branch back to trunk to integrate those bug fixes.

    1. Why would bug fixes be cherry picked and merged into release branches it's implied that bug fixes are done in a release branch and that release branch is merged to master?

    While you're working on stabilizing the software in the release branch, the rest of the team may find a bug in trunk that also exists in release. If that happens, you'll want to integrate the bug fix in the release—however, you can't just merge trunk into release, because that would bring along all the new stuff the team has been working on while you were preparing the release. So, instead, you cherry-pick just the commits that fix the bug and nothing more.

    1. Assuming code is not directly pushed to a release branch, why would the release branch be merged back into master/trunk if it was forked from master?

    See answer number 1. Note that merging a release branch back to trunk may lead to a lot of merge conflicts if the code in trunk is too far ahead from what was originally chosen for the release. For example, you may have fixed a bug in release, but the modified files are no longer in trunk due to a refactoring.

    It's also worth mentioning that release branches are not always worth the additional overhead. The document you linked to offers an example:

    In cases where releases happen multiple times a day, release branches are not required at all, because changes can be pushed directly into master and deployed from there.

    The goal of trunk-based development is to simplify the process of developing software by reducing the number of branches you have to maintain to just a single one.