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

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?

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.