How does git flow handle hotfix to older release or point release of older release

Peter Kahn picture Peter Kahn · May 3, 2016 · Viewed 7.4k times · Source

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

Answer

Hugo Ferreira picture Hugo Ferreira · May 5, 2016

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: