In git flow, there is a point where you decide to create a branch from the current develop being the new release. For example 1.7. Everthing that is ready to this point is considered beeing in that release, everything after this point is a new release (e.g. 1.8). Only bugfixes should go into the current release branch. The advantage is, that the current dev branch can still go on with further feature implementation without beeing "blocked". This seems to be a pretty linear flow where one release follows on another.

But how to handle successfully multiple releases in parallel using git flow?

The customer on the one hand wants to have a new version that have breaking changes (considered then as 2.x) but it is also not compatible with current main branch (1.x). On the same time the customer wants smaller features on the current 1.x branch to be released periodically until the 2.x is released.

Is git flow an approriate tool for this or should one consider switching to other strategies? If yes, which one is appropriate?

For example, how would on handle an additional 1.7 release with smaller features when there are already breaking changes on the current dev branch? I mean there are breaking changes which then can not be considered beeing a new 1.7 release. Would you just use the 1.6 branch as the base for the next 1.7? But how to handle features that are in 1.7 but should also be in the new 2.x branch (which might change a lot in the meanwhile)?

1 Answer 1


You don't need to make things complex. Create a 2.x branch from develop. Periodically merge develop into 2.x. When a bugfix is applied to a 1.x branch, be sure to merge the 1.x branch into develop, and then merge develop into 2.0. Roughly speaking, it translates to these git commands:

git branch 2.0 develop
git checkout 1.3
# fix code, commit, push
git checkout develop
git merge 1.3
git checkout 2.0
git merge develop

The assumption is that 2.0 is always ahead of the 1.x branches. Conceptually, the 2.0 branch should have everything that exists in develop and the 1.x branches with the addition of breaking changes specifically built for 2.0.

  • Hi Greg, thanks for your response. It sound reasonably to me. Sure, what i stated feels complex, but also this is because thinking of too much edge cases especially regarding timelines ... one question left: when would then someone merge the new 2.0 branch "back" to develop and state is as the new, not backward compatible dev branch? I would suggest when all 1.x feature requests are done. But like i said, what when someone requires a 1.x feature because 2.0 cant be deployed because it takes still time? Or is the definite production-ready-state of 2.0 the crucial point?
    – Jim Panse
    Jul 26 at 10:16

Your Answer

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

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