18

We are trying to adopt gitflow into our process at work. Gitflow is pretty simple when it comes to hotfixes. However, I'm unclear on how I would fix a bug on a previous version of our system.

For example, let's just say we're on version 8.1.3 and I need to make a bugfix to 7.1.5. I could create a branch based on the 7.1.5 tag, but then how do I get that back into master and tag it? Is that even possible using Git? I was thinking of just keeping the release branches and commit and tag there, but I'm not sure if that is the proper way to do things.

Robert
  • 667
  • 7
  • 15
  • According to Git Flow, you wouldn't fix 7.1.5 at all; it's too late for that. Instead, you would create a hotfix branch stemming from your latest release (8.1.3), fix the bug there, and then merge that hotfix branch into master, thereby creating a new release (8.1.4?). See the [red commit on the nvie diagram](http://nvie.com/posts/a-successful-git-branching-model/). – jub0bs Feb 27 '15 at 15:03
  • 1
    Sometimes clients want to stay on a particular version of our system, but going from 7.0 -> 8.0 would introduce major changes. The whole process of creating a hotifx and merging to master/develop make sense, I just felt like that was the most relatable example. I'm just not sure how to support clients who use previous major versions of our system. – Robert Feb 27 '15 at 15:12
  • The Git-Flow model doesn't make provisions for that case. – jub0bs Feb 27 '15 at 15:14
  • We're in the same situation (multiple stable releases supported at the same time) - I've added our process as an answer. – nwinkler Feb 27 '15 at 15:21

2 Answers2

15

Git-flow in its original model does not talk about supported major versions at the same time. It does not describe a model where you have the following versions in production:

  • 7.1.5: Two customers are using this
  • 8.2.3: Three customers are using this
  • 9.0.0: This is the next major version that you're currently working on.

In Git-flow, the master branch is your currently supported, released version, everything else is old and considered legacy.

Having said that, and since we're in the same situation, where we have to support multiple major versions at the same time (at least one where we provide bug fixes, and one where we provide new features), we have come up with the following:

  • develop and master: These are the branches for the current work. Anything that goes into the next major version is done here.
  • Once we do a new stable release (e.g. 7.3.0), we create the following branches:
    • 7.3/develop
    • 7.3/master

These branches now become the develop and master branch for this supported release. Any fixes we need to do on v7.3.0 are done in the 7.3/develop branch, and once we create release v7.3.1, it's done on 7.3/develop and 7.3/master.

Changes that need to be done in both develop branches are usually cherry-picked, since we don't want to merge the new features from develop into an older, but still maintained develop branch.

This process takes a bit of setup, but it works quite well, and as long as you remember to create the required branches when you start working on the next stable version, it's not too much overhead.

nwinkler
  • 52,665
  • 21
  • 154
  • 168
  • just to make sure: in the approach you suggest, the 7.3/master and 7.3/develop branches will never be merged back to the main development branches, will remain "detached" forever right? – rickyviking May 20 '16 at 10:01
  • Yes, that's true - they are separate release versions. Sometimes we cherry-pick individual commits where it makes sense, but never merge between `7.3/develop` and `develop`. – nwinkler May 20 '16 at 10:51
2

one way could be:

  • create a branch "7.1" on which you create bugfixes (7.1.6, ...)
  • cherry-pick your modifications to put them on top of master as well (where you would tag again, but with another tag: 8.1.4)

not sure this is the best way, but a possibility.

Chris Maes
  • 35,025
  • 12
  • 111
  • 136