Managing several versions with GitFlow
Tags: git, gitflow, bestpractices
Published: 2019-04-25 17:23:51

---
title: Managing several versions with GitFlow
published: true
tags: git,gitflow,bestpractices
canonical_url: https://mindsers.blog/en/several-versions-gitflow/
---

I recently wrote a [post about GitFlow](https://mindsers.blog/en/gitflow-methodology-practice/) 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` : 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...