17

How does git flow handle a hotfix after master has move far beyond that release?

Scenario

  1. Work for 1.0 performed on develop, stabilized on releases/v1.0 release branch and pushed to master in fast-forward merge with tag v1.0 pointing to tip of master and tip of stabilization branch
  2. Releases 1.1 - 3.2 take place in much the same fashion.

  3. We need to hotfix a bug in 1.0

    • branch from v1.0 tag
    • perform fix
    • merge to where?

Master is far in the future and any merge wouldn't be a fast forward and for fun, let's say would conflict.

Would I merge to release stabilization branch and make new tag? Is that what subsequent hotfixes would use as their starting point?

Git Flow Example

Peter Kahn
  • 12,364
  • 20
  • 77
  • 135
  • 1
    It doesn't, git glow assumes you only have single "live" version. – 1615903 May 04 '16 at 04:49
  • That said, you can always checkout a tagged release, create a new hotfix branch there, and proceed as usual. – 1615903 May 04 '16 at 04:51
  • Actually I think GitFlow is especially suited for dealing with multiple versions in the wild. I only use it and recommend it precisely for “packaged” sw (where the user downloads/installs). If it's web (1 single live version) I would use a more simple flow like GitHub Flow, for example. – Hugo Ferreira May 04 '16 at 21:18

1 Answers1

6

nvie’s section on hotfix branches explains these are…

… very much like release branches in that they are also meant to prepare for a new production release, albeit unplanned.

So, they are meant to be done on the top of the latest master version, when current stuff in develop isn't ready for the normal release cycle.

What you want here for patching an older version is the concept of support branches, which was discussed a long, long time ago after the initial git flow past was publish but, afaik, never been throughly documented.

The gitflow-avh tool does seem to support them well, so you might want to explore it in a test repo:

I did find some posts with “information” on support branches but wasn’t too happy with their explanations… given the lack of information about them, i’ll link them anyway:

Hugo Ferreira
  • 1,584
  • 16
  • 17
  • I agree the documentation on support branches is nonexistent, maybe even documentation in general needs a better write up. With git-flow AVH, you can create a hot fix from a support branch, and when you finish it it will merge back into the support branch. The problem arises when you also want to update the other releases with the same hot fix. It would have to be done through patching or cherry picking. For anyone wanting to weigh in on this discussion see the issue on github. https://github.com/petervanderdoes/gitflow-avh/issues/161 – Peter van der Does May 05 '16 at 17:48
  • 3
    Can you give a list of git commands to answer the question? I mean to answer "merge to where?" in the question. @PeterKahn has a specific problem, so could you give the corresponding solution? – FreeLightman Dec 01 '16 at 14:25
  • @FreeLightman merge to nowhere! :) “hotfix branches” are not the answer here and “support branches” are derived from a tag and stay a long running branch until the that old version is deprecated. – Hugo Ferreira Dec 15 '16 at 14:05
  • So following your suggestions, releases (in their most up-to-date state) are both tags on the master branch AND hotfix branches? Try keeping up with that. I'd rather have consistency: every release branched off instead of just tagging it. Then it's annoying to forthport hotfixes done on a very old version, but at least it's easy to keep track of the HEAD of each version. – klaar Feb 22 '18 at 13:26
  • @klaar in gitflow, hotfix branches are short lived, so the _only_ definition of a release is the tag on master. Using support branches you branch off the master tag only when you need to update/maintain/patch an older version further back, which you want to keep to a minimum precisely _not_ to have to keep up with supporting diverging codebases. – Hugo Ferreira Feb 23 '18 at 11:54
  • You can disregard my comment, because I expressed my concern of not having a branch for *every* main version, but since in Gitflow versions are tracked through tags and not branches, this is not really an issue. When in the case of having to patch a very old version, a branch of main has to be made to incorporate patches and then tag the Nth commit on that branch, it might look unnatural when looking at the branches, but I just realised that we should just look at the tags anyway! – klaar Feb 23 '18 at 13:43