We've tried to adopt Gitlab flow with release branch as out team's branch management strategy. The developers just:

  1. to do feature development, they checkout a branch from master then merge it to master sooner or later, simple
  2. for bug fix, adopt the "Upstream first" policy. Whenever possible, checkout bug fix branch from master then merge it to master and cherry-pick it to release branches.

Basically it works well. However, we meet some requirement now, that some of our release branches are likely to use some features that have been merged into the active-developed master, but not all of them.

I know that from any online materials that i can find, new feature into release branch is basically forbidden. However, we just need it for now (maybe we should not call it release branch but something like "canary branch"). One might argue that we should use another release branch to support this. But as i said, the boss just want some feature in master, not all of them, so we cannot just checkout a new release branch from

I can only think of two ways to handle such use case under our current workflow:

  1. Just cherry pick the feature commit from master to the release branches that needed it, then tag a new release version. The cons is that many of time, the cherry-pick cannot be that "clean", it might need some precedent commit in master branch, which might accidentally bring some "unwanted" change into the release branch lts
  2. follow https://cwiki.apache.org/confluence/display/TS/Release+Management, create new release branch like v8.(x+1) directly from previously release branch v8.x, then pick the feature commit in master to the newly created release branch. pic

Which one of the solution is better? Or is there any better approach? Any advice is sincerely appreciated.

Why do we might need to apply some "not bug fix" commit to already existed?

In fact we are developing a fingerprint recognition SDK, basically all stuff inside the SDK can be categorized as:

  • neural network model(as separate file)
  • strategy(basically the code)
  • configuration(like some thresholds, some are coupled with model and strategy)

We will test and analysis the SDK algorithm accuracy offline by mock input video stream(image files) before release. However, accidents occurs all the time after the SDK is integrated into the software used by real users. So we might need to adjust the strategy(which means rewrite some code) then apply it to the released version(release branch).

One might argued that this should be considered as bug fix, or quoted from Martin Fowler:

accepts commits accepted to stabilize a version of the product ready for release

  • 1
    How many versions of your software are you supporting? I'm thinking that there is a disconnect between your software release strategy, your branching strategy, and your strategy for developing new features or bugfixes. If you support one version of your software in production, you can do different things than if you have to support N versions of your software for different users.
    – Thomas Owens
    May 10 at 11:46
  • Simultaneously, two or three. In fact we are providing a SDK, and the software guys integrate it and publish the software like once a month. Basically they integrate a new release version each time. But they still need two support two or three older version at the same time. So for us, we have one active-developed master branch and two or three need-to-support release branches May 11 at 3:53
  • That helps, but can you elaborate a little more on the versions. Do you need to support two or three major versions and more minor versions? Or is it just the last two or three versions released? Can you also expand a bit more on the features that you are merging in? It doesn't make much sense to me to add new features to a released minor version - the updates there should be bug fixes or security patches only.
    – Thomas Owens
    May 11 at 11:38


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.