Search code examples
gitsvnrelease-managementgit-flow

GIT Flow and support of parallel software versions

my company is switching to GIT (from SVN).

I have been reading this about GIT flow:

http://nvie.com/posts/a-successful-git-branching-model/

And I don't understand, how I can fit it to our current release schema.

Current release schema

enter image description here

Let's say the corporate divison of our company issues software X.

Our team developps packages / modules for the software.

Sometimes, over the different versions of the software, we don't need to change anythings, only mild bug fix =>See package 2.

Sometimes, the corporate guys issues in some area many design changes and we have to create version specific adjustments (code, documentations or configurations) => see package 1 or 3.

How it's being dealt with at the moment in SVN:

working with the trunk / branch layout. If you get something version specific, let's say for code in package 1, you will find a V12, V14, V15, V16 and V16 sub-directories with the versions specific changes. Our release tools (ANT / Jenkins ) deals with this complexity.

My question:

In the GIT flow, the release branches are being deleted, merged back to master and tagged there.

How do you deal with bug fixes in legacy versions (in my example Client 4)?

How do you deal with clients who wants to acquire a legacy Version of a Package (Client 1 upgrade plan)?

(In the real life, we have 100+ packages and 20+ clients)

I've read these but didn't find answer to my question:

Git-flow and master with multiple parallel release-branches

Git flow: Best practice for dealing with minor releases

Multiple development branches with git-flow

Thanks for your help

Solution

  • Based on what you are describing, this would be what I refer to as support branches. In a utility that I work on called GitVersion, we describe these here:

    https://gitversion.readthedocs.io/en/latest/git-branching-strategies/gitflow-examples/#support-branches

    Support branches are not really covered in GitFlow, but are essential if you need to maintain multiple major versions at the same time. You could use support branches for supporting minor releases as well. If you are just supporting the majors, then name your branch support/.x (i.e support/1.x), to support minors use support/..x or support/..0. (i.e support/1.3.x or support/1.3.0)