在我工作的地方，我们有一个分支策略，基本上说有一个最顶层的main（称之为主，主干，等等）总是稳定的，然后是一个项目组，然后是一个项目，两者都有他们的相应的main分支（取自一个级别“向上”，更靠近最顶层的主要分支）。在项目层面，根据所涉及工作的复杂程度，可能会或可能不会对特定功能进行进一步分支。 （例如，无需创建功能分支来修复一些已识别的用户界面文本拼写错误。）通常，这很有效。我们还将控制数据库层作为较大源代码树的一部分来源控制，因此每个源根目录下都有一个database结构。
在database子树中，有一个patch目录（在大多数分支中）有一个子目录。该目录以vCurrent命名（例如，如果vCurrent是2.3 SP1 HF0，那么补丁目录将命名为2.3 SP1 HF0）并包含将升级数据库模式（可能带有数据转换）的补丁v当前为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的补丁可能适用也可能不适用，但最重要的是，必须由负责每个分支的开发人员根据具体情况决定。 因此，将创建一个具有新当前版本号的新补丁目录，并删除旧补丁目录，因为它不再相关（通过选中“显示已删除的项目”，它仍可从源代码管理中获得，如以及发布drop分支，因此获取特定版本的内容不是问题）。将此变更集合并到各自的功能分支时，每个开发人员都应查看其数据库补丁集并根据需要进行更新，以符合来自上游的任何架构更改。
通常情况下，这不是一个大问题，因为补丁结构的更改是在最顶层的main（再次，稳定）和向下滴。
但是，如果第二个（发布的）功能分支及其自己的一组数据库补丁，TFVC将逐步删除主2.3 SP1 HF0上的删除操作补丁目录似乎不考虑第二个功能分支已将内容添加到已删除目录的事实，并删除这些新补丁以及patch\2.3 SP1 HF0 。这显然是不可取的。
在我看来，功能分支2中的情况是冲突：合并的一侧表示删除，另一侧表示从未合并到合并源的新文件。在那种情况下，TFVC应该放弃，将其视为冲突，并询问正在进行合并的程序员该做什么。请注意，该目录下甚至可能存在具有相同名称但内容不同的文件（这是设计使然）。相反，它只是通过完全删除目录及其所有内容从地下拉出地毯。
目前，我们主要通过在删除时执行“撤消挂起更改”，然后移动新补丁并手动删除旧目录来处理此问题。这显然是次优的，并且风险极大（所有这一切都需要一个开发人员在从上游合并“次要”更改之前不检查其完整的挂起更改集，而他们在本地有新的数据库补丁，并且您已丢失工作和沮丧）。
在TFS和TFVC的范围内工作（所以请不要说“在DVCS模式下使用Git”或类似内容），有没有办法让这个实际上出现冲突？或者我们是否运气不好，只需要满足于手动处理这种情况？它不会经常发生，但是由于分支数量很多，显然存在错误滑倒的风险。
答案 0 :(得分：0)
您可以同时使用git和tfs。查找git-tfs。充分利用这两个世界。最大的收获是你将不再需要处理基础较少的合并。这是您问题的核心。合并时，将共同基础中的冲突建立在冲突双方的基础上是非常有益的。
在git中没有“dvcs模式”，BTW。
我们为每个功能做积极的分支。这是或工作流程：
https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR
技术除外，我希望它可以帮助您解决分支机构问题。至少在tfs中，如果你手动标记一些开发工作的开头，你可以比较两边的补丁。