1

I've been looking at using git flow, but there seems to be a hole in the original design around hotfixes.

Say you've done several releases - your master has tags for 0.1, 0.2, 0.3, 1.0, 1.1, 2.0, etc. You find a bug in 0.2, and want to do a release 0.2.1 with a fix. Where does the release tag go? It can't go onto master, as that's on version 2.0. Does it just go on the hotfix branch? And can that branch then be used to create a 0.3.1 and 1.1.1 release in a similar way, with the tag on the 1.1.1 hotfix branch, and merged into a pending release branch?

thecoop
  • 45,220
  • 19
  • 132
  • 189
  • 1
    Possible duplicate of [Git-flow and master with multiple parallel release-branches](http://stackoverflow.com/questions/16562339/git-flow-and-master-with-multiple-parallel-release-branches) – Vampire Apr 08 '16 at 15:46
  • Here, I'm specifically asking about a fix to an old version that has to be merged back into newer versions sequentially until it reaches master – thecoop Apr 08 '16 at 15:53
  • The answer to that question answers your question also, doesn't it? – Vampire Apr 08 '16 at 15:55
  • Kind of - do you create a separate hotfix and cherry pick the changes from wherever for every support release you want to do? And those support branches just stay around forever? – thecoop Apr 08 '16 at 16:02
  • I don't know, I do not use git-flow but as far as I have read, the support branches are beta and not really production-ready, so their meaning and handling might change. – Vampire Apr 08 '16 at 16:04
  • The concept of support branches is that they stay around for as long as the related release is still being maintained, without being merged to master - since any fix there is either irrelevant for newer release, or comes from a fix done in a newer release. – yossiz74 Apr 10 '16 at 07:40
  • from what i can understand it, it does not matter if the problem was introduced in version 1. the production has already moved to 2. so whatever fix is being introduced, has to be part of the next release and needs to be merged into the top... i could be wrong, but introducing the fix at 1.0 would make it look like the v 1.0 release had the fix.. when the fix was actually introduced in your 2.1 release... – s5v Apr 13 '16 at 11:18

1 Answers1

1

Even though the original gitflow never "upgraded" the support branches you will run into another problem. The original git-flow does not let you create a hotfix from a support branch to start with.

To start of, I'm assuming you use Semantic Versioning 2.0.0 as in x.y.z

To answer your question as I see it: You use support branches for releases, now the question of course is how many support branches would you keep and create. Personally, if you would support older versions, I would keep branches for x.y releases.

Tags would go on on the support branches.

If a hotfix needs to be implemented all the way up the releases, there are two ways you could do this:

  • Cherry pick like you suggested.
  • Create a patch and use the patch for other releases.

If the hotfix is only one commit I guess you could do a Cherry Pick, if it's more I would go for creating patches with git format-patch and use git am to add them to other branches.

Now again to be able to create a hotfix/bugfix/release branch from a support branch you need to use gitflow AVH Edition (Disclaimer: I developed gitflow AVH Edition)

Peter van der Does
  • 14,018
  • 4
  • 38
  • 42