我一直在阅读Adam Dymitruk的git工作流程，这一切都很有意义。
我找不到任何关于修复旧版本中的错误的讨论。想象一下"主"分支的标签为7.0、7.1、7.2、7.3、7.4、7.4.1、7.4.2、7.8、8.2，以及最新的8.3
特定客户端的生产版本是7.2，并且发现了一个错误，必须修复。
在8.3.1中修复它并将客户端从7.2移动到8.3.1是客户端无法接受的。
那么，有推荐的工作流程吗?
我可以从7.2标签创建一个主分支的分支，称这个分支为release-7.2。然后，处理release-7.2。就像对待主分支一样——从基线创建一个功能分支(72bug)，修复bug，等等，最终将功能分支合并到release-7.2中。X’，进行构建，生成7.2.1标记，并将其投入生产。"发布- 7.2。X '将永远存在，就像主人一样，所以任何更多的修复到7.2。X可以在release-7.2.x上生成。
当然，我们不希望失去7.2版本对当前工作的修复，所以我们可以从当前主基线(8.3)创建一个特性分支，并将bug分支(72bug)合并到这个特性分支中。这个特性分支应该像当前发布周期/冲刺中的其他特性一样被对待。因此，在周期结束时，最新的基线(8.4)将包含错误修复。
其他人如何使用Adam的工作流程来处理这种情况?
如果您不能将客户端迁移到当前版本，那么就真的没有办法绕过从7.2标记开始新的分支。
而不是在72bug分支上修复错误并将其合并到版本7.2中。但是，我建议修复当前功能分支上的错误，然后使用git cherry-pick将修复反向移植到版本7.2。x分支。这将有助于保持您的历史记录干净，这样您当前的开发就不会仅仅因为一个客户端的需求而突然依赖于较旧的版本。