合并到子分支会导致 TFVC 中新的子分支内容被删除，如何修复？

Question

在我工作的地方，我们有一个分支策略，基本上说有一个始终稳定的最顶层的main（称之为main、trunk，等等），然后是一个项目组，然后是一个项目，两者都有自己的各自的 main 分支（取自“上”一级，更接近最顶层的主分支）。在项目级别，可能会也可能不会对特定功能进行进一步的分支，具体取决于所涉及工作的复杂性。 （例如，无需创建功能分支来修复一些已识别的用户界面文本拼写错误。）一般来说，这种方法效果很好。我们还将数据库层作为更大源代码树的一部分进行源代码控制，因此每个源代码根目录下都有一个数据库结构。

在database 子树中，有一个patch 目录，其中（在大多数分支中）有一个子目录。该目录以 vCurrent 命名（例如，如果 vCurrent 为 2.3 SP1 HF0，则补丁目录将命名为 2.3 SP1 HF0），并包含将升级数据库的补丁从 vCurrent 到 vFeature 的架构（可能包含数据转换）。这里的 vFeature 是相关分支投入生产的版本；如果开发由于某种原因没有成功，可能是 vNext、vFuture 或（在极端情况下）vNever。功能分支通常没有目标发布版本，但可能有目标发布日期。

因此，结构如下所示：

main
    database
        patch
            2.3 SP1 HF0 <--- indicating that "main" is at version 2.3 SP1 HF0
projectgroup1
    main
        database
            patch
                2.3 SP1 HF0
    project1
        main
            database
                patch
                    2.3 SP1 HF0
        feature1
            database
                patch
                    2.3 SP1 HF0

现在，假设在生产中发现了一个严重错误，需要立即修复，结果将 main 推送到版本 2.3 SP1 HF1。或者管理层决定发布一个版本（可能仅发布一个功能分支）以满足市场需求，为我们提供 2.4 SP0 HF0。或者无论如何。版本中未应用的“来自”2.3 SP1 HF0 的补丁可能仍然适用，也可能不再适用，但最重要的是，这必须由负责每个分支的开发人员根据具体情况决定。 因此，将创建一个具有新的当前版本号的新补丁目录，并删除旧的补丁目录，因为它不再相关（通过选中“显示已删除的项目”，仍然可以从源代码管理中获取它，如以及发布分支，因此获取特定版本的内容不是问题）。当将此变更集合并到各自的功能分支时，每个开发人员都应检查其数据库补丁集并根据需要进行更新，以符合来自上游的任何架构更改。

通常，这不是一个大问题，因为对补丁结构的更改是在最顶层的 main 处进行的（同样，它是稳定的）并向下渗透。

但是，如果第二个（对于已发布的）功能分支存在及其自己的数据库补丁集，TFVC 似乎会在 main 的 2.3 SP1 HF0 补丁目录上进行删除操作不考虑第二个功能分支已将内容添加到已删除的目录，并删除这些新补丁以及patch\2.3 SP1 HF0。这显然是不可取的。

在我看来，功能分支 2 中的情况是一种冲突：合并的一侧说删除，另一侧说从未合并到合并源的新文件。在这种情况下，TFVC 应该靠边站，将其视为冲突，并询问正在进行合并的程序员该怎么做。请注意，该目录下甚至可能存在名称相同但内容不同的文件（这是设计使然）。相反，它只是通过彻底删除目录及其所有内容来彻底删除您的脚下的地毯。

目前，我们主要通过在删除时执行“撤消挂起的更改”来处理此问题，然后手动移动新补丁并删除旧目录。这显然感觉不是最理想的，而且风险极大（所需要的只是一个开发人员在合并来自上游的“较小”更改之前没有检查其全套待处理更改，而他们在本地有新的数据库补丁，并且您已经失去了工作和很多挫折）。

在 TFS 和 TFVC 的范围内工作（所以请不要说“在 DVCS 模式下使用 Git”或类似的内容），是否有办法真正将其呈现为冲突？或者我们是这样吗？运气不好，只能手动处理这种情况？这种情况并不经常发生，但由于分支数量众多，显然存在犯错误的风险。

Answer 1

您可以同时使用 git 和 tfs。查找 git-tfs.两全其美。最大的好处是您不必再处理无基数合并。这是你问题的核心。合并时，将冲突建立在共同基础上对冲突双方都是非常有利的。

顺便说一句，git 中没有“dvcs 模式”。

我们对每个功能都进行积极的分支。这是工作流程：

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

抛开技术不谈，我希望它能帮助您解决分支机构问题。至少在 tfs 中，如果您手动标记某些开发工作的开始，则可以比较双方的补丁。