1

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

Community
  • 1
  • 1
R..
  • 113
  • 7

1 Answers1

0

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)

Gary Ewan Park
  • 17,610
  • 5
  • 42
  • 60
  • Thanks for your feedback. Just to clarify: in fact the support branching strategy you point out corresponds more or less to the git flow, with one difference: we don't delete release branches to support them in the future, correct? One of the reason people started to create version specific sub-directories in SVN was to avoid to have to create too much branches . Now Git is another tool and might be better to deal with branches but in your opinion, how does it make the life easier compared to the SVN version specific subdirectory strategy? – R.. Oct 28 '16 at 13:28
  • (just as background, we are also to switch from Jenkins / Ant to Bamboo / Ant) – R.. Oct 28 '16 at 13:29
  • No, not quite, or at least, not to my understanding. Even if you started using (long term) support branches, you would still have release branches that get opened and closed during the development effort. A branch in SVN was a very heavy weight object that essentially copied the entire directory structure. Branches in git on the other hand are a much more light weight object, and switching between them is very simple and quick operation. – Gary Ewan Park Oct 28 '16 at 13:38