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): enter image description here 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
  • Imagine the problem is found after merge1. If you branch the hotfix from master, you won't be able to merge it into release/1.0 without bringing feature/001 with it.
    – jonrsharpe
    Commented Oct 23, 2021 at 9:52
  • @jonrsharpe I made a mistake in the title -- I meant to say "cherry-pick from master" (i.e. trunk-based development) rather than doing a regular merge from master into the RC. I updated the title and description.
    – voobaroo
    Commented Oct 23, 2021 at 10:19

2 Answers 2


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

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.