Git Braching/Merging strategy: release + hotfix branches, what's the point of master

Question

I am working on a git based branching/merging strategy that would cater to the needs of my organization: I referred to GitFlow(link: https://datasift.github.io/gitflow/IntroducingGitFlow.html)

and started to fit various scenarios to it. It is all good for the normal development using feature branches and releases using release branches. However, it gets complicated when it comes to hotfixes. Several different versions of our product is deployed to various clients and we need to be able to deploy hotfixes for all the clients. I believe GitFlow assumes that only the latest version of the product is deployed in production and the strategy caters to that one scenario by creating tags on the master branch for each release. If a hotfix is required, a new hotfix branch could be created from the last tag from master and changes merged back into master and develop and to continue from there. In my case however, I might need to deploy a hotfix to a version which is several releases behind master and I can't simply merge it back into master. I have to merge it back to the original release branch and develop branch. I have to keep track of all the release branches and version them appropriately.

I am wondering if there is an elegant solution to this situation. Moreover, because I am no more taking a hotfix branch from the tag on master and merging back into master, what's the point of having both a develop and a master branch? I don't need the develop branch. The features branches could directly be merged to master and at the time of release, I could create a release branch from master and once ready, can merge it back into master. Any suggestions?

Answer 1

As mentioned here, Gitflow is ideally suited for projects that have a scheduled release cycle.

Develop and Master Branches

Instead of a single master branch, this workflow uses two branches to record the history of the project. The master branch stores the official release history, and the develop branch serves as an integration branch for features. It's also convenient to tag all commits in the master branch with a version number.

So:

I have to merge it back to the original release branch and develop branch. I have to keep track of all the release branches and version them appropriately.

I am wondering if there is an elegant solution to this situation

Not really: back porting an hotfix needs to be evaluated on a release-by-release basis (some of the releases might not need to fix)
But you don't need to merge it to a develop branch (unless the fix is still relevant for the next release), only to an release branch.

what's the point of having both a develop and a master branch? I don't need the develop branch

master records each new release (and all its commits represents an new release).
From each release, a release branch can be created to host any evolution (like a new back-ported fix)