我一直在阅读Adam Dymitruk's git workflow，这一切都很有道理。
我找不到任何讨论的一件事是修复旧版本中的错误。使用7.0,7.1,7.2,7.3,7.4,7.4.1,7.4.2,7.8,8.2和最新的8.3
标记标记'master'分支在特定客户端的生产中，版本为7.2，并且找到了一个错误，必须修复。
将其修复为8.3.1并将客户端从7.2移至8.3.1对客户来说是不可接受的。
那么，是否有推荐的工作流程？
我可以从7.2标签创建主分支的分支，调用此分支版本-7.2.x然后，像处理主分支一样处理'release-7.2.x' - 从基线创建一个功能分支（ 72bug），修复bug等，最终将功能分支合并到'release-7.2.x'，进行构建，制作7.2.1标签，并将其投入生产。 'release-7.2.x'将继续存在，与master一样，因此可以在7.2.x版本上对7.2.x进行更多修复。
当然，人们不希望从当前工作中丢失7.2的修复，因此可以从当前主基线（8.3）创建一个功能分支，并将bug分支（72bug）合并到此功能分支中。此功能分支将被视为当前发布周期/冲刺的任何其他功能。因此，在周期结束时，最新的基线（8.4）将包含错误修复。
其他人如何使用Adam的工作流程来解决这种情况？
答案 0 :(得分：0)
如果您无法将客户端迁移到当前版本，那么从7.2标记启动新分支真的无法实现。
不是修复72bug分支上的错误并将其合并到release-7.2.x分支和当前功能分支中，我建议修复当前功能分支上的错误，然后使用{{1将修复程序反向移植到release-7.2.x分支。这将有助于保持您的历史记录清洁，以便您当前的开发似乎不会因为一个客户的需要而突然依赖于旧版本。