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

Question

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

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

做一个简短的总结:

• ma​​ster 分支有一个代表生产版本的标签。
• develop 分支是准备下一个版本的地方。这是每晚进行测试的分支。以及夜间构建的分支。
• Feature-Something 分支，其中创建下一个功能，并在 develop 分支的末尾 merge 。此分支应仅位于开发人员存储库中。
• Fix-Something 分支，其中进行了热修复，可以在 develop 和 master
上 merge
• Release-1.2 分支是为下一个版本准备上次修复和更改的地方。当它准备好用于生产时，它在 master 和 development 上 merge 。

很喜欢，但是好像有那么一两点不符合我们的一些要求:

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

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

我们考虑过这样的事情:

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

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

• 我认为与此工作流程不兼容的另一点是pull-request。我们想使用一个pull-request系统，即当某人完成一个功能或修复一个bug时，他必须在他想要 merge 他的工作的分支上进行一个pull request。

但我想知道 - 如文章链接中所述 - 如果功能或错误的每个分支都应该只打开开发人员计算机无法使用 pull 请求？我想我们必须先在 GitHub 上推送分支，然后再请求 pull-request，对吗？

最后，您如何看待这个工作流程？适合 4-10 名开发人员的小团队吗？你有什么建议可以让它变得更好吗？您有更好的工作流程吗？

Answer 1

所以你必须维护两个平行的稳定分支。虽然 git 使分支相当容易，但维护软件的并行版本会消耗大量资源。预计这在任何情况下都会很痛苦。

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

• 估计两个平行稳定分支的生命周期。他们活得越久，最终付出的努力就越多。
• 想想您期望在哪个分支上进行多少事件。特别是 1.0 系列是否仅用于偶尔的重要和错误修复，或者那里是否会有重要的开发事件。在后一种情况下，您应该尽量让两个分支彼此靠近。

我可以想象两种变体:

• 1.0.x 仅修复了罕见的重要错误。然后，开发分支应该基本上接近 1.2 并在每个 1.2 版本中 merge 到那里，您可以将罕见的错误修复直接返回到 1.0 分支。

• 1.0.x 获得重要功能。那么你应该在一个实际上接近 1.0.x 的分支上开发那些特性。这可以是一个单独的开发分支。

在着手过于复杂的分支模型(这可能很容易使团队感到困惑)之前，请务必阅读 this article .