具有许多发行版本的软件开发的最佳工作流程

Question

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

我读了这篇文章：http://nvie.com/posts/a-successful-git-branching-model/

做一个简短的总结：

• 主分支有一个代表生产版本的标记。
• 开发分支是准备下一个版本的地方。它是每晚进行测试的分支。和夜间建筑的分支。
• 功能分支，其中包含下一个功能，并在 develop 分支的末尾合并。此分支应仅在开发人员存储库中。
• Fix-Something 分支，其中包含修补程序，可以在 develop 和 master
上合并
• Release-1.2 分支是下一个版本准备好的最后一个修补程序并进行了更改。它在准备生产时合并在主和开发上。

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

• 首先，我们的软件有 1.0 版本的客户端和 1.2 版本的客户端。我们不会将客户端从1.0迁移到1.2，因为我们不再支持Unity 3.4在更高版本上支持Unity 3.4。但我们的一些客户仍在使用它。

但是现在，想象一下，我们在产品的核心中发现了一个错误，我们必须为每个版本修复它。使用此工作流程执行此操作似乎很复杂，无需重复提交...

我们考虑过类似的事情：

当修补程序适用于每个生产分支时，通过这个新的修改工作流，我们只需将其合并到每个分支上。这就是为什么我们想要通过主要版本发布分支。

但这是一个很好的工作流程吗？这个工作流程的缺点是什么？职业选手？我认为这可能有点令人困惑......

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

但是我想知道 - 正如链接一文中所解释的那样 - 如果功能或错误的每个分支都应该只在开发人员计算机不能使用pull-request？我想在请求 pull-request 之前我们必须在 GitHub 上推送分支，对吗？

最后，您如何看待这个工作流程？对于一个4-10名开发人员的小团队来说，它没问题吗？你有什么建议让它变得更好吗？你有更好的工作流程吗？

Answer 1

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

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

• 估算两个平行稳定分支的寿命。他们生活的时间越长，最终会花费你的成本。
• 考虑一下您对哪个分支机构的预期活动量。特别是，1.0系列仅用于偶尔的import和bug修复，或者那里会有重要的开发活动。在后一种情况下，您应该尽可能地保持两个分支彼此靠近。

我可以想象两种变体：

• 1.0.x只获得罕见的重要错误修正。然后，开发分支应该基本上接近1.2，并在每1.2版本中合并，你可以将这些罕见的错误修正直接回到1.0分支。

• 1.0.x获得了重要功能。然后，您应该在实际接近1.0.x的分支上开发这些功能。这可能是一个单独的开发分支。

在开始过于复杂的分支模型（可能很容易让团队迷惑）之前，请务必阅读this article。