We have to support multiple releases, so we are following git branching model similar to the above diagram. Now the problem is that we have to do lots of merging here example for fix/011, we are merging it three different branches(master, release/1.0 and release/2.0). Also there is question of from where to create this fix/011 branch from master, release/1.0 or release/2.0? Creating it from master brings unwanted features, creating it from any release branch brings merging overheads and conflicts and cherry pick back to master is error-prone.
Is there any better approach? We can't follow single release branch approach because our different customers are on different releases and many times they don't want to do major upgrade to get fix for small issue(and there are pricing aspects as well)
We are using github.
One good option I found is forking fix(/feature) branch from all branches (refer: https://docs.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops#port-changes-back-to-the-master-branch) but our developers didn't find it much different from exiting approach and they feel is complex.
Best Answer
The thing to remember is that merging a fix also merges all its ancestors, so if you want to keep code in
2.0out of1.0, your merges should always go from1.0to2.0, and never the other way around. That means fixes need to be made (or rebased onto) the oldest branch possible, then merged into the second oldest, then into the third oldest, and so forth. This takes a lot of discipline, as usually developers prefer to work on the bleeding edge, and only think about the maintenance branches as an afterthought.