This post is free for all to read thanks to the investment Mindsers Blog's subscribers have made in our independent publication. If this work is meaningful to you, I invite you to become a subscriber today.
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:
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
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
develop exists : the
It is very simple :
supportbranch gets created from
masterwith 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
- When you have a security update to make on version 2.7, you create a
support/2.7.xas if it was
master. It is, in fact, the master of the maintained 2.7 version.
- When the fix is done, you merge your
- You delete the
hotfixbranch and tag
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
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…
Join 100+ developers and entrepreneurs and get notified on every new content.
No spam ever. Unsubscribe in a single click at any time.
If you have any questions or advices, please create a comment below! I'll be really glad to read you. Also if you like this post, don't forget to share it with your friends. It helps a lot!