Visual Studio 2008：如何避免项目文件合并地狱？答案

【问题标题】：Visual Studio 2008: how to avoid project file merge hell?Visual Studio 2008：如何避免项目文件合并地狱？
【发布时间】：2011-01-28 05:14:46
【问题描述】：

当您与多个开发人员一起处理 VS C# 项目时，这些开发人员都将新项目和文件添加到同一个解决方案中，最后一个尝试签入他的更改的人会在项目解决方案文件上遇到冲突，这并不容易合并。

我发现解决此问题的最简单方法是取消我自己的更改并接受服务器的最新版本。然后我重新整合我自己的变化。根据添加到项目中的新文件的数量，这可能很容易，也可能是非常烦人的任务。

我想知道是否有更简单的方法可以做到这一点。阅读：我可以让 VS/TFS/merge 为我做这个吗？

【问题讨论】：

合并 XML 文件有什么难处？
根据我的经验，自动合并在处理项目文件方面并不算太糟糕，它为您提供了该选项（您目前正在解雇！）。
您添加项目的频率如何？当您的架构预先布局时，将项目添加到解决方案不应成为日常任务。也许您甚至应该制定一条规则，即开发人员应该询问高级开发人员或架构师是否可以添加项目。即使添加文件也应该很少见。
@Joel - *.sln 文件不是 XML。它们是文件格式的流产，其中顺序和编号以难以言喻的愚蠢方式很重要。
@Richard - 他们就是这样。我猜想的是项目文件，而不是解决方案文件，因为“新文件添加到项目中”这句话。

【解决方案1】：

我的建议是更频繁地更新和提交。特别是，请确保在对解决方案文件进行任何更改之前运行“获取最新”。

“合并地狱”与诸如 XML 和文本文件（所有项目和解决方案文件都是）之类的东西通常只发生在人们试图提交非常大的单个更改时。

如果您养成定期提交的习惯，合并往往会更小，而工具往往会做得很完美。

【讨论】：

我还建议您让您的员工在不确定如何合并解决方案文件时停下来并提出问题。我在一个每周必须手动清理解决方案文件几次的地方工作，因为人们会自动合并而不是检查结果。（而且 SLN 不是 XML。）
@Reed，我一定不同意。您是否真的针对两个人添加了新项目的 *.sln 文件运行了自动合并工具？由于项目分配编号的方式，它实际上是不可能成功的。
@Richard：如果你经常更新和提交，这永远不会发生。就个人而言，我让我的团队总是在提交之前更新。我个人觉得添加的新项目应该是它自己的提交。这意味着您更新、提交任何更改。然后添加你的项目，并提交它。基本上，你永远不应该合并两个“新”项目，除非两个人试图在相同的几分钟内添加一个新项目（非常不可能）......
@Richard：如果您尝试将单个项目合并到 .sln，它可以正常工作。我一直这样做...
@Reed - 在提交之前更新不会改变任何东西。这是有问题的顺序：（1）A 在本地添加一个项目（2）B 在本地添加一个项目（3）A 提交。在这一点上，B做什么并不重要。 Update & Commit [aka Get & Checkin in TFS lingo] 将触发完全相同的冲突。这将要求他手动编辑 SLN 文件或恢复 + 重新应用他的更改。

【解决方案2】：

我制作了一个专门用于比较/合并解决方案文件的工具（也可用于动态创建过滤解决方案）。

可以在以下位置找到：http://slntools.codeplex.com/

【讨论】：

【解决方案3】：

我从不向解决方案添加文件，只向项目添加文件。如果您需要添加文件，请将它们添加到项目中。

如果您不想合并，那么另一种方法是，如果有人签入带有新项目的解决方案，然后将该项目和解决方案拉下，覆盖您自己的解决方案文件，然后将您的项目重新添加到解决方案并重新签入。现在解决方案既有他们的项目也有你的。

【讨论】：

有些文件很高兴有一个解决方案作为参考。我过去使用的示例是第三方程序集、强命名键、一般注释和共享配置文件。
我将这些放在一个空项目中。问题是解决方案使用的“虚拟”文件夹可能会导致您在机器之间出现不一致。当您在不同的机器上签出解决方案和文件时，它们可能与添加文件的开发人员所在的相对目录结构不同。解决方案还允许引用诸如“..\..\OutsideFolder”之类的文件，当其他开发人员试图从源代码管理中提取解决方案时，这可能会造成严重破坏。
我同意 aaronis 的观点，即您需要小心相对路径。但是，正如 Matthew 解释的那样，将第三方程序集添加到解决方案中是很正常的。我总是做的是为解决方案目录中的第 3 方 dll 创建一个名为“共享程序集”的目录，并创建一个具有相同名称的解决方案文件夹。这样我就不会遇到 aaronis 描述的任何问题。
这正是我已经在做的，但我希望有更好的方法:)

【解决方案4】：

我也非常厌倦项目文件的合并问题。（有一次我试图在一个项目文件中解决 9000 多个冲突。）

所以我做了一些事情：http://www.projectmerge.com

虽然它最初是一个项目文件比较/合并工具，但它很快演变成可以比较和合并任何 XML 文件的工具。

希望你觉得它有用。

【讨论】：

【解决方案5】：

添加到 cmets 池的一个建议 ...

在提交时尽量减少对 SLN 文件所做的更改，以便其他人更容易合并。

（当然，其他人也一样）。

为了说明，假设您的 SLN 文件当前列出了四个项目：

SLN: A, B, C, D

您和一位同事都进行了更改。你添加了项目 E，加上（出于某种原因）事情被重新排序：

Yours:  A, E, D, C, B

您的同事更改涉及添加项目 F：

Co-Worker: A, B, C, D, F

如果您按原样提交更改，那么您的同事必须面对合并这两者：

SLN: A, E, D, C, B
Co-Worker: A, B, C, D, F

讨厌。

相反，如果您（小心！）尽量减少差异，您可以使您的工作副本看起来像这样：

Yours:  A, B, C, D, E

在这种情况下，当您的同事需要合并时，他们将不得不面对：

SLN: A, B, C, D, E
Co-Worker: A, B, C, D, F

更容易合并。

【讨论】：