This is the one thing that I find lacking in trunk-based development. I work on multiple products that have a release branch for each minor release, and it works incredibly well other than this as a minor pain point.
I find the easiest way is that if you know you want (or even think you might want) a particular fix in a patch version, you can make a branch from the oldest release branch you want to support. When you create a PR, you can easily target to the release branch (or another later release branch) or master, depending on what you want. You can even do multiple PRs to merge it multiple places.
No matter how you go about it, it should always be safe to merge a release branch back into master. In fact, this is a good thing to do after you release a patch version, but can also be done whenever you need a particular fix in newer (master, or other feature branch code) code immediately.
Merging release branches like this makes following a fix significantly easier than if you do it with cherry picking. Consider if you're looking at bug ticket, and trying to figure out what branches/releases it was fixed in. If the PR was merged to master, then later cherry picked to an older release, all you'll see is it was in master. Unless someone manually comments about it or your tooling picks it up based on references, the only other thing to do is check the code itself to see if the fix is there. When you instead merge forward, even if the ticket comments are wrong or not there, you can literally follow the branches from the PR/commits and see every release it got into.
> Unless someone manually comments about it or your tooling picks it up based on references.
I don't find this to be overly burdensome on the tooling. If the ticket-tracking system can't automate traceability between git commits and tickets, then it isn't well-suited to git-based software development.
We use the following policy:
- A bugfix commit must fix the bug, the whole bug, and nothing but the bug. If that seems impractical for the task at hand, make it practical by breaking up the bug's ticket into smaller elements.
- The bug tracking system observes the git tree and maintains its own linkage to it.
- When cherry-picking the bugfix to other affected branches, pass the `-x` argument to `git cherry-pick`.
That's it. The (cherry-picked from) comment helps out when just viewing the git history on its own. And the bug tracking system lets you quickly see all of the commits and pull requests that referred to the bug.
I find the easiest way is that if you know you want (or even think you might want) a particular fix in a patch version, you can make a branch from the oldest release branch you want to support. When you create a PR, you can easily target to the release branch (or another later release branch) or master, depending on what you want. You can even do multiple PRs to merge it multiple places.
No matter how you go about it, it should always be safe to merge a release branch back into master. In fact, this is a good thing to do after you release a patch version, but can also be done whenever you need a particular fix in newer (master, or other feature branch code) code immediately.
Merging release branches like this makes following a fix significantly easier than if you do it with cherry picking. Consider if you're looking at bug ticket, and trying to figure out what branches/releases it was fixed in. If the PR was merged to master, then later cherry picked to an older release, all you'll see is it was in master. Unless someone manually comments about it or your tooling picks it up based on references, the only other thing to do is check the code itself to see if the fix is there. When you instead merge forward, even if the ticket comments are wrong or not there, you can literally follow the branches from the PR/commits and see every release it got into.