3

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

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

做一个简短的总结：

  • 主分支有一个代表生产版本的标签。
  • 开发分支是准备下一个版本的地方。它是每天晚上运行测试的分支。以及夜间构建的分支。
  • Feature-Something分支，用于制作下一个功能，并在最后合并到开发分支。此分支应仅位于开发人员存储库中。
  • Fix-Something进行热修复的分支，可以在开发和主控上合并
  • Release-1.2分支是准备下一个版本并进行最后一次修复并进行更改的地方。当它准备好用于生产时，它会合并到master和development上。

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

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

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

我们想到了类似的东西：

Git 工作流程

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

但这是一个好的工作流程吗？这个工作流程有什么缺点？优点？我觉得这可能有点混乱...

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

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

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

4

1 回答 1

0

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

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

  • 估计两个平行稳定分支的寿命。他们活得越久，最终花费的精力就越多。
  • 考虑一下您期望在哪个分支上进行多少活动。特别是 1.0 系列只是为了偶尔的重要和错误修复，还是那里会有重大的开发活动。在后一种情况下，您应该尽量让两个分支彼此靠近。

我可以想象两种变体：

  • 1.0.x 仅获得罕见的重要错误修正。然后，develop 分支应该基本上接近 1.2 并在每个 1.2 版本中合并，您可以将罕见的错误修复直接挑选回 1.0 分支。

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

在开始使用过于复杂的分支模型（这可能很容易让团队感到困惑）之前，请务必阅读这篇文章。

于 2013-07-15T22:20:15.913 回答