Question about pushing fixes to release branches

[Daniel D'Aquino]

Hi Will and team,

I have a question regarding about how we manage and push fixes when we are managing `master` and a release branch.

Let’s say we have a release branch called `release_X`, we have two milestones on Github: (“release_X" and “future_release”), and a developer is working on a given Github ticket that is part of milestone `release_X`.

So the developer locally creates a new branch based off of the `release_X` branch, writes the patch, and sends it with a base commit on that same release branch.

When we push the fix, which one is more appropriate:

1. Apply the patch (`git am`) on top of `release_X` branch, and then merge `release_X` onto `master`, OR
2. Apply the patch on top of both `release_X` and `master` branches (either by doing `git am` on both branches, or by doing `git am` on release + `git cherry-pick` on `master`)?

I imagine option (1) is better because:

• everything on the release branch should become part of `master` anyways
• we don’t duplicate the same commit in two places (We would have one canonical commit in the git history)

But what are your thoughts on this? Would there be a reason to go for option (2) instead?

Best regards,

Daniel

[William Casarin]

On Wed, May 01, 2024 at 05:54:52PM GMT, Daniel D'Aquino wrote:
>Hi Will and team,
>
>I have a question regarding about how we manage and push fixes when we are managing `master` and a release branch.
>
>Let’s say we have a release branch called `release_X`, we have two milestones on Github: (“release_X" and “future_release”), and a developer is working on a given Github ticket that is part of milestone `release_X`.
>
>So the developer locally creates a new branch based off of the `release_X` branch, writes the patch, and sends it with a base commit on that same release branch.
>
>When we push the fix, which one is more appropriate:
>

>- Apply the patch (`git am`) on top of `release_X` branch, and then merge `release_X` onto `master`, OR
>- Apply the patch on top of both `release_X` and `master` branches (either by doing `git am` on both branches, or by doing `git am` on release + `git cherry-pick` on `master`)?

>
>I imagine option (1) is better because:
>

>- everything on the release branch should become part of `master` anyways
>- we don’t duplicate the same commit in two places (We would have one canonical commit in the git history)

I was doing option (1), but then I realized it can be annoying, if there
are commits meant to be only on that branch, such as a commit that
changes the version number in the project settings to the release
version.

In that case you just need to make sure to revert any change you don't
want before you merge.

The downside of 2 is that you may forget to cherry-pick something, a
merge ensures you got everything applied to the release branch.

I think (1) is fine.

[Daniel D'Aquino]

Thanks! I will try to try option (1) next time, following these guidelines