Managing several versions with GitFlow

Nathanaël Cherrier -

I recently wrote a post about GitFlow where I explained what it was and how to use it in most cases.

Since that, I got a lot of feedback from readers concerning the use of GitFlow in some specific cases. In particular, in the case of a project where several versions are maintained.

Let's explain that.

I develop and maintain a framework

The basic running of GitFlow works in most of the cases, as we saw it. But let's talk about a particular case where a development team works on one of the latest famous framework.

This team uses GitFlow and is very happy with it. Things are progressing, and we are now at version three.

Every new project made by outside devs are in the latest version, but there are still projects using the previous version of the framework.

If a security breach is discovered, the outside devs expect the team to apply corrections on version 3 but also on version 2.7 of the project. It is normal.

This team has to maintain two versions of their project simultaneously. Our problem comes from the strict branch system of GitFlow:

  • feature : from develop to develop
  • release : from develop to develop and master
  • hotfix  : from master to develop and master

If developers have to do a hotfix on version 2.7 of the framework (security fix), they can not create the branch from master because they already are at version 3 in this branch.

They can not reapply the corrections on master and develop either because in version 3 the code might have completely changed and might not be compatible.

How can you represent two simultaneous versions of your project in the index?

The support branch

I haven't told you everything about GitFlow. There is a secret rule in the workflow that can solve our problem.

A fourth type of branch derived from master and develop  exists : the support branch.

It is very simple :

  • The support branch gets created from master with the following format support/2.7.x. The starting point must be the last commit of version 2.7 of the project and not the most recent commit of the master branch.
  • When you have a security update to make on version 2.7, you create a hotfix/2.7.1 branch from support/2.7.x as if it was master. It is, in fact, the master of the maintained 2.7 version.
  • When the fix is done, you merge your hotfix on support.
  • You delete the hotfix branch and tag v2.7.1 on the support/2.7.x branch.

In the project, we have :

  • master ⇒ in version 3.0
  • develop ⇒ development in progress of version 3.1
  • support/2.7.x ⇒ in version 2.7
  • feature/...
  • release/...
  • hotfix/...

A little automation ?

Yes and no. This feature, even if it is really easy to apply for a human, is hard to implement for a machine to automate.

There are commands git flow support ..., but they are still in development/test/experimentation. Plus, they are not well documented.

You can use it, but you may encounter some bugs. If you feel adventurous, go for it! It will only help the dev but try not to use it on critical projects…