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 projects 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
: fromdevelop
todevelop
-
release
: fromdevelop
todevelop
andmaster
-
hotfix
: frommaster
todevelop
andmaster
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 frommaster
with the following formatsupport/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 themaster
branch. - When you have a security update to make on version 2.7, you create a
hotfix/2.7.1
branch fromsupport/2.7.x
as if it wasmaster
. It is, in fact, the master of the maintained 2.7 version. - When the fix is done, you merge your
hotfix
onsupport
. - You delete the
hotfix
branch and tagv2.7.1
on thesupport/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...
Top comments (0)