多个版本的软件开发最佳工作流

Question

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

我读过这个：http://nvie.com/posts/a-successful-git-branching-model/

作一个简短的总结：

• 主分支有一个表示生产版本的标记。
• 开发分支是准备下一个版本的地方。它是每天晚上进行测试的分支。以及夜行建筑的分支。
• Feature-Something分支，在这里生成下一个特性，并在开发分支的末尾进行合并。这个分支应该只在开发人员存储库中。
• 制作热点补丁的Fix-Something分支，可以在开发和主程序上合并
• 版本-1.2分支是下一个版本准备的地方，使用最后一个修复并进行更改。当它准备好生产时，它就会在掌握和发展的基础上被合并。

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

• 首先，我们的软件在1.0版本上有客户端，有些在1.2上。我们不会将客户端从1.0迁移到1.2，这是因为我们在以后的版本中不再支持Unity3.4。但我们的一些客户还在使用它。

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

我们想到了这样的事情：

​

​

有了这个新的修改后的工作流，当补丁适用于每个生产分支时，我们只需将其合并到每个分支。这就是为什么我们考虑在主发行版上有一个分支。

但这是一个很好的工作流吗？这个工作流的缺点是什么？专业人士？我觉得这有点让人困惑..。

• 我认为与此工作流不兼容的另一点是pull- request。我们希望使用一个pull-request系统，也就是说，当某人完成一个特性或修复一个bug时，他必须对他想要将他的工作合并到其中的分支发出一个拉请求。

但是我想知道--正如文章中所解释的那样--是否每个分支都应该只在开发者计算机上才能使用拉请求呢？我想我们必须先在GitHub上推动分支机构，然后再请求拉请求，对吗？

最后，您对这个工作流有什么看法？对于一个由4-10名开发人员组成的小组来说还行吗？你有什么建议让它更好吗？你有更好的工作流程吗？

Answer 1

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

关于这种情况的一些一般性提示：

• 估计两个平行稳定分支的寿命。他们活得越久，你最终付出的努力就越多。
• 想一想你期望在哪一个分支上有多少活动。特别是1.0系列只是为了偶尔进行导入和错误修复，还是会有重要的开发活动。在后一种情况下，您应该尽可能地保持两个分支之间的紧密联系。

我可以想象出两个变体：

• 1.0.x只得到罕见的重要错误修复。然后，开发分支在本质上应该接近于1.2，并在每一个1.2版本上合并到其中，您可以选择将罕见的错误直接返回到1.0分支。
• 1.0.x具有显著的特性。然后，您应该在实际上接近1.0.x的分支上开发这些特性。这可能是一个单独的开发分支。

在开始一个过于复杂的分支模型(这很容易使团队感到困惑)之前，一定要阅读这篇文章。