git - 分支策略 - 维护多个版本

Question

多年来，我们一直使用 TFS (TFVC) 作为我们的版本控制系统。无论如何我们可能会迁移到 git，但我正在努力弄清楚

1) 是否有比我们目前使用的更明智的分支策略/模型，专门用于维护多个生产版本(通常针对多个不同的客户)？

2) 关于 1)，与 TFVC 相比，git 是否有特定的优势？

我们今天做的其实很简单:

Mainline ----------------------------------------------------
             |          |          |          |          |         
        Release 3  Release 4  Release 5  Release 6  "Release" 7

所有版本在主线上都有自己的分支，即使是 future 版本的开发工作也是在“ future ”版本分支上完成的。在上面，“Release 7”正在进行中，尚未发布。

在这些分支中的每一个下可能还有更多的子分支，例如功能分支，以隔离工作并保持发布分支稳定，但我认为这对于本次讨论并不重要。

每当这些发布分支之一发生变化时，它最终必须 merge 到主线并从那里 merge 到所有 future 的版本，以避免客户从版本 3 到版本 5 的回归。

在实践中，对这些“旧”分支的更改不仅是小错误修复，而且可能是版本 3 上的客户所请求的更大的功能，它是在版本 3 中开发的，客户会收到版本 3 的新版本。最终该功能将 merge 到主线，并从那里 merge 到所有 future 版本。

由于 merge 总是从主线上的每个分支到每个较新的分支发生，这实际上意味着主线与最新发布的分支基本相同。

这是第一个令人头疼的问题:从旧版本 3 merge 到非常新的主线，然后从主线 merge 到旧版本 5 有一些不自然的事情(实际上它不时会导致问题)。可能有例如，在将版本 3 与版本 6 进行比较时，会发生较大的重大变化。直接从第 3 版 merge 到第 5 版会自然得多，但 TFVC 不支持这种做法。您只能 merge 到您的直接父级(或子级)。 git 有同样的限制吗？

另一个问题是，如果它的变更集不在历史记录中的一个连续的、不间断的 block 中，则在 TFVC 中不可能挑选 merge 整个功能。如果来自其他功能的变更集是交错的，则您要么必须将每个连续的子 block merge 到功能变更集中，要么必须 merge 从源分支到目标分支的所有内容。并且进行多次挑选 merge 并不总是可能的，因为构建或单元测试可能需要所有变更集，甚至可能。我明白为什么 TFVC 有这个限制，因为该功能的新变更集可能建立在另一个功能的旧的、交错的变更集之上。因此，仅 merge 最初来自此功能的变更集甚至可能没有意义。在实践中，我们倾向于 merge 所有准备 merge 的东西，它无论如何都必须在某个时候 merge 。 git 在这方面比较如何？

对于我们的案例来说，什么是明智的分支策略/模型？迁移到 git 对我们有帮助吗？

Answer 1

TFVC (CVCS) 和 git (DVCS) 之间存在很大差异。而 git 的简单工作流程通常如下:

• feature 分支通常从develop 分支创建，用于开发新功能或修复错误。他们通常在做空分支。功能或错误完成后，应 merge 到 develop 分支。

• develop 分支用于所有开发人员将他们的作品(功能和错误) merge 到其中。

• master 作为管理项目稳定代码的主要分支。 QA 团队可以测试将 develop 分支 merge 到 master 分支。

所以分支结构是这样的:

...-----------------   master
           /   ... /
...----------------    develop
     \  /   \   /
      --     ---
  feature1    featuren