tfs - 在 TFS 中，一个分支的父子关系的方向很重要

Question

分支之间的父子关系的方向重要吗？
父/子只是一个抽象的概念，标识哪个是源，哪个是目的地，还是存在只能在一个方向上执行的特定操作，因此，使关系的方向变得重要？

这里有一些背景信息来解释这个问题的原因..

我们最近实现了一个新的分支策略，并决定采用这个简单的设置:

Dev -------------------------------
          \
      Main >-----------------------
                  \
        Production >---------------

这似乎对我们有用，但我阅读的所有推荐指南都表明 Main 应该是根。所以它应该是这样的:

      Dev  >-----------------------
          /
Main ------------------------------
                  \
        Production >---------------

这很相似，但显然 Main 和 Dev 之间的父子关系是相反的。

如果我们将 Dev 作为根并将 Main 作为它的子项，我们会给自己带来什么问题？我能看到的唯一问题是，如果我们从 main 中取出第二个 Dev 分支。它与 Main 的父子关系将与另一个 Dev 分支相反，但我再次问这有什么意义？

感谢您的浏览，如果您需要更多信息，请告诉我。

Answer 1

短期:短期内告诉大家将 DEV 视为 MAIN 的 child ，即使它在 TFS 中看起来像 parent 。

注意:您可以在 TFS 中重新设置 DEV 分支...如果您认为特定团队的概念术语和流程风险将大于更正 TFS 分支结构的风险，则可能应该这样做。

其他想法

我会回应分支方向在技术上对 TFS 并不重要。但是要非常小心那些更容易混淆的人类。重要的是，在分支之间进行合并(或创建新分支)的每个人都清楚地了解分支层次结构并遵循您的团队的官方术语和分支/合并过程。

MAIN(又名 Root 或 Trunk 或 Ancestor 分支):
您可以任意指定任何分支为“Main”、“root”、“trunk”等分支。请记住，这些术语通常可以互换使用，尤其是对于从不同公司雇用的新开发人员。只要每个做合并和分支的人都知道您将 MAIN 分支视为团队的根/主干分支，那么您就可以了。如果您随意要求某人在根分支上发布新版本，而他们决定 root=DEV 分支，那么您就有问题了(即使您的分支图明确支持“根”分支是 DEV 的想法)。

合并方向:
FI(从父级到子级的正向集成)和 RI(从子级到父级的反向集成)是用于描述合并方向的最常用术语。我订阅了 FIRI(“Fiery”)合并模式，以确保在 RI 合并到父级之前，父级中的所有更改都被 FI 合并到子级(解决所有冲突并根据需要进行测试)。这确实有助于保持父分支比子分支更稳定。这个想法对您的问题很重要，因为目前 FI 暗示从 DEV(父)到 MAIN(子)。如果您和所有分支/合并人员都可以始终假装 DEV 是子分支，那么您可以说“您在合并到主分支之前做了 FI 吗？”。同样，您团队的分支/合并公会可以明确声明“ 重要提示: 在本指南(以及一般讨论)中，始终将 DEV 分支视为 MAIN 的子分支，即使技术上是 TFS 中的父分支(截至 4/25/2012)。”
那么在讨论 DEV 分支时，所有语句都可以使用标准术语，而不必经常使用反向术语。

(如果您已经在团队中使用了其他术语，例如“合并”和“合并”，那也可以……只要包括新员工在内的每个人都清楚地了解这些术语的含义。(还要注意“向上”和“down”分支在不同公司的绘制方式不同，因此该术语可能会引起混淆。)

新分行:
如果您的团队决定从 MAIN 创建一个新的 DEV_FeatureX 分支，那么它将是一个子分支。 (TFS 强制每个分支只有一个父级......你目前不能是两个母亲所生的 child :-)。同样，如果你按发布分支(现在或以后)，这些分支将是 MAIN 分支的新子级.随着时间的推移，这将

请记住，计算机犯错误的频率远低于人类。
享受! -泽芬