Git – Avoiding the Grid of Doom™ in Git-Flow

You seem to be branching off on every major release (12.0.0), then having possible minor updates to each (12.1.0), and hot fixes (12.2.1). Correct?

There's no specific reason why you cannot keep release branches alive in GitFlow after a release is out, other than the fact that coordinating changes between multiple diverging branches for a long time is hard with any model. I suppose GitFlow was also modeled more for products that maintain a single live release while developing the next.

I would stick with GitFlow and make a few amendments;

Skip the master branch. I've had no practical use of it so far, and it would lose its linearity the way you work. Keep development on the next major release on develop. If you decide to keep master, don't put release tags on master, put them on the last commit on the release branch that produced the binary you're shipping.

Don't throw away the release branches after you merge them back to develop. Instead keep them around for the next minor release and possible hot fixes. If you ever stop supporting a release, I suppose it's fine to delete them. You could name release branches after their main component, release/12, and then create sub-release branches, release/12.1, release/12.2 off of it. I've not had to worry too much about this level of parallelism, but that's probably what I'd try. You can think of each major release branch as its own sub-GitFlow environment in this case.

If you must be working in parallel on features for several future major releases at the same time, perhaps you have to keep the next one (13) on develop and anything for later versions (14, 15) on additional "develop-N" branches. That does seem very hard to maintain in general, but would be possible.

In Gitflow Workflow, an hotfix is a branch that is created from master and in the end is merged back in master AND in develop.

The general (and well known) idea behind the "don't directly commit on master", is to have in master, a state of your code that is completely safe to deploy in production.

However, it can serves other means. For Github, the master also serves as a tracking tool to know when a feature is put in production. If you commit on another branch and then fast-forward master on it, you will lose the merge commit, and by extension, you'll just put a lot of tiny commits in your master timeline, losing the ability to revert a whole feature by simply revert the previous merge.

Another problem with this approach, is to know WHEN you can release/deploy. If everyone commit on master, you will have to synchronize all the development to have a coherent state of your code. For monolithic releases with a clear scope, it can be ok, but in my case, as an integration developer, features come and go and you have never a single point in time when "all features are done".

However, not commit in master does not mean having a branch master and a develop. As pointed in the Github presentation, if you do a feature branch workflow, you can work only with a master, creating a branch for each feature, and merges them back in master (without fast-forward) at the end.

In my humble opinion, Git Flow (master/develop + features/hotfix/release branches) is more adapted in a context where you don't really know when you'll have to release it (not at each feature done), and when the last release is often the one to hotfix. A gitflow chart can be convoluted, while a feature branching workflow is often more simple to read. The "noise" is often due to release/hotfix commit in what will be deleted branch some minutes after.

Example for Gitflow

Example of graph for Feature Branching Workflow