Git 具有多个发布版本的软件开发最佳工作流程

我们目前正在使用Git更改我们的工作流程，以避免最大限度的错误和回归

我读了这篇：

做一个简短的总结：

• 主分支有一个表示生产版本的标记
• develope分支是准备下一个版本的地方。它是每晚运行测试的分支。以及夜间建造的分支
• 特性某事物分支，其中生成下一个特性，并在开发分支的末尾合并。此分支应仅位于开发人员存储库中
• 修复某些问题制作热修复程序的分支可以在“开发”和“主控”上合并
• Release-1.2分支是使用最后一个补丁准备下一个版本并进行更改的地方。当它准备好生产时，它在主控和开发阶段合并

我真的很喜欢，但似乎有一两件事与我们的一些要求不符：

• 首先，例如，我们的软件在1.0版本上有客户端，在1.2版本上有一些客户端。我们没有将客户机从1.0迁移到1.2，原因很简单，我们不再在更高版本上支持Unity 3.4。但我们的一些客户仍在使用它

但是现在，假设我们在产品的核心中发现了一个bug，并且我们必须为每个版本修复它。在不重复提交的情况下使用此工作流执行此操作似乎很复杂

我们想了一些类似的事情：

当修复程序适用于每个生产分支时，有了这个新修改的工作流，我们只需将它合并到每个分支。这就是为什么我们考虑在主发布版本旁边有一个分支

但这是一个好的工作流程吗？此工作流的缺点是什么？职业选手？我想这可能有点让人困惑

• 我认为与此工作流不兼容的另一点是

  pull-request

  。我们想要使用一个

  拉请求

  系统，也就是说，当某人完成一个特性或修复一个bug时，他必须对他想要合并工作的分支发出拉请求

但我想知道——正如链接文章中所解释的那样——功能或bug的每个分支都应该只在开发人员的计算机上，这一事实是否使得pull请求的使用变得不可能？我认为在请求拉取请求之前，我们必须在GitHub上推送分支，对吗

---

最后，您对该工作流有何看法？对于一个由4-10名开发人员组成的小团队来说，这样可以吗？你有什么更好的建议吗？您有更好的工作流吗？

因此您必须维护两个并行的稳定分支。虽然git使分支变得相当容易，但维护软件的并行版本会消耗大量资源。无论如何，这都是痛苦的

有关此场景的一些一般提示：

• 估计两个平行稳定分支的寿命。他们活得越久，你最终付出的努力就越多
• 想一想你期望在哪个分支上有多少活动。特别是，1.0系列只是为了偶尔的导入和错误修复，还是会有重大的开发活动。在后一种情况下，应尽量使两个分支尽可能靠近对方

我可以想象两种变体：

• 1.0.x只得到罕见的重要错误修复。然后，开发分支本质上应该接近1.2，并且在每一个1.2版本中都会合并到1.2中，您可以直接将罕见的错误修复返回到1.0分支

• 1.0.x具有重要的特性。然后，您应该在实际上接近1.0.x的分支上开发这些特性。这可以是一个单独的开发分支

在开始一个过于复杂的分支模型（这很容易让团队感到困惑）之前，一定要阅读