When creating a fix, how does branching off the release candidate branch compare with cherry-picking from master?

Question

When we have bug/hotfix for the release candidate, we branch off of the RC branch and merge that fix back into the RC branch. We also merge (git merge, not cherry-pick) that fix into the master branch (red arrow): Is this any better than simply using trunk-based development? (Better meaning less merge conflicts, less headaches, etc.)

Edit: To be clear, I want to compare between these two methodologies:

1. branch off of RC; create the fix; do normal merge back into RC; then merge that fix into master
2. branch off of master; create the fix; merge that into master; and also cherry-pick into the RC

Answer 1

The Git-Flow branching strategy enables you to keep one or more software versions around on their own branches for support purposes. For example, you could be developing a future 15.0 release on the main branch, while keeping a release branch for v14.x and v13.x as long as you still support these versions.

Let's assume a bug was introduced in v14.x and you want to fix it.

• If you create the fix on the main branch and then merge the fix into the v14.x release branch, then you will also be merging all of the new features intended for v15 into the v14.x branch.
• Cherry-picking would avoid that problem, but then you would have multiple commits with distinct identity in your repository.
• Instead, Git-Flow recommends that you create a hotfix branch from the release branch, and then merge the hotfix into all branches that need it. This avoids pulling in features that you don't want on that branch, and assists with the secondary Git-Flow goal of only recording merge commits on certain branches.

But who even needs to maintain multiple versions of the software? Git-Flow is well suited for companies or other projects that guarantee long support for old software versions. But for anyone else, it's an unnecessarily complicated workflow. Even the author of the Git-Flow is surprised that it seems so popular. Examples where having release branches is unnecessary and trunk-based development or the Github Flow is sufficient are:

• SaaS products or other "continuously delivered" software where you (as the developer) can upgrade the software at any time
• more generally, software that is only deployed by a single organization
• software where only the latest version is supported, and there is no other supported upgrade path

Answer 2

The process of fixing bugs in the RC branch is helpful when you have a QA process for the release candidate 1.0 which overlaps in time with the new feature development for the next RC 2.0.

Imagine the fixes coming from issues detected by a manual testing process. You fix them, one after one, but since this process goes over a few weeks, other feature branches are integrated into master as well, potentially modifying things which were already tested in the current test cycle, hence introducing a certain risk of invalidating the work of the testers.

On the other hand, when most of your test processes run fully automated, and you have a lot of confidence that half-baked features (which should not be visible in RC 1.0) are hidden well behind feature flags, so even bugs in those new features' code don't won't influence the release, then you can omit a separate RC branch and use trunk based development instead.