Question

多年来，我们一直使用TFS（TFVC）作为我们的版本控制系统。我们可能会迁移到git，但我想弄清楚

1）是否存在比我们目前使用的更合理的分支策略/模型，特别是用于维护多个生产版本（通常针对几个不同的客户）？

2）关于1），git对TFVC有特定的好处吗？

我们今天所做的事实上很简单：

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

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

在这些分支中，可能还有其他子分支，例如功能分支，以隔离工作并保持发布分支稳定，但我认为这对于此讨论并不重要。

每当其中一个发布分支发生变化时，它必须最终合并到主线，并从那里合并到所有未来版本，以避免客户从第3版到第5版的回归。

在实践中，对这些＆＃34; old＆＃34;的更改分支机构不仅是小错误修正，而且可能是第3版客户请求的更大功能，它是在第3版中开发的，客户收到第3版的新版本。最终，该功能将合并到主线，并从那里到所有未来版本。

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

这是第一个令人头疼的事情：有些不自然（实际上它会不时引起问题）关于从旧版本3到主线的合并，这是非常新的，然后是从主线到旧版本5。例如，在将版本3与版本6进行比较时，要进行大规模的更改。直接从第3版合并到第5版会更自然，但TFVC并不支持。您只能合并到您的直接父母（或孩子）。 git有同样的限制吗？

另一个问题是，如果TFVC中的变更集不在历史记录中的一个连续，不间断的块中，那么在TFVC中不可能合并整个特征。如果来自某些其他要素的变更集是交错的，则您必须将每个连续的子块合并到要素更改集中，或者必须合并从源分支到目标分支的所有内容。并不总是可以进行多次樱桃选择合并，因为建立或单元测试甚至可能需要所有变更集。我可以看到为什么TFVC具有此限制，因为该功能的较新变更集可能基于来自另一个功能的较旧的交错变更集。因此，仅合并最初来自此功能的变更集可能甚至没有意义。在实践中，我们倾向于合并所有准备合并的东西，它必须在某些时候合并。在这方面git如何比较？

对于我们的案例，什么是合理的分支策略/模型，迁移到git会对我们有帮助吗？

Answer 1

TFVC（CVCS）和git（DVCS）之间存在很大差异。 git的简单工作流程通常如下：

feature分支通常是从develop分支创建的，用于开发新功能或修复错误。他们通常会缩短生活分支。功能或错误完成后，它应合并到develop分支。
develop分支用于所有开发人员合并其作品（功能和错误）。
master作为管理项目稳定代码的主要分支。质量检查小组可以测试将develop分支合并到master分支。

所以分支结构如下：

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

分支策略 - 维护多个版本

1 个答案: