As far as I understand a GIT wokflow is described in the following way: http://nvie.com/posts/a-successful-git-branching-model/
I have a question related to old branches bugfixing in this workflow.
Given we have plenty of older release branches merged into master branch. Our last release was release say 2.6. We need to fix some bug found in some old release branch, say 1.5. We create a branch from master branch state related to release 1.5, fix it, deploy it and thats ok. But now a question remains: how can we STORE and PROPAGATE this change to all the newer releases?
We cannot just merge this fix into master. Because the class we were fixing may be removed in release 2.3, for example. Its just may be absent in the HEAD of master branch.
Not sure we can merge it into the history of master. I cannot imagine how it should change all the commits.
So looks like after the hotfix ALL the next commits of master branch are out of date and cannot be used. And if we have some bug in 1.9 release then the only option we have is to make a branch from 1.9 commit from master, merge it somehow with that 1.5 hotfix and go on then..
Is my understanding correct?
The mentioned work flow does not include the case you mentioned. If the old class does not exist in newer releases, this means that the bug might not even exist as well, so the bugfix should not be propagated to that new releases. Also you don't need to merge it to the master history, as the master represents the current product state (in the hand of customer), which is way ahead in releases. Keep in mind that changing the history of any old node will change all the history chain of the next nodes.
To solve this issue it is better to make a new branch, called for instance "Support-1.5" which contains the updates related to the support of that specific old version of the product, merge your related bugfixes to it, and this support branch lives as long as that old version of the product is supported.
Hope this helps.