我通常使用Git进行版本控制。在我的团队中，我们并行工作，我们经常将代码提交到应用程序中。一切都很好但是Visual Studio的解决方案和项目文件。我们找到了两种方法：
这两种方式都有优点和缺点，但基本上我们每次从中央回购中获利都会挣扎。这里有一些我们发现的备用问题:(在实施中，对上面列表的引用）
.csproj个文件（2）等等。 我可以使用适当的工作流程吗？
答案 0 :(得分：17)
提交.sln和.csproj文件通常是最佳做法（如this answer中所述），但合并需要引起注意。
请参阅“Why are my .csproj files getting messed up after a git rebase?”。
（见下文）*.csproj -text merge=union
*.sln -text merge=union伏
或者您可以放弃.csproj并在本地as in this tweet重新生成它们
忽略这些csproj文件的另一个原因是它们是否被重新生成，如in this context
yellowblood警告（in the comments）与csproj文件一起使用merge=union文件时发生的严重冲突问题。
这与文章“Merge conflicts in csproj files”相呼应
这就是为什么有一个suggestion for VS IDE should support file patterns in project files（为了不修改.csproj文件，如果添加一个符合该模式的新.cs文件的话。）
有人建议，如果Visual Studio首先对其元素进行排序，这将有助于缓解问题 这有助于减少由Visual Studio明显的非确定性元素引起的偶然冲突 但它并没有使合并冲突的问题消失。
答案 1 :(得分：6)
在我们的项目中，我们将这些检查到版本控制中。我们从github的.gitignore和简单的.gitattributes文件开始：
# Auto detect text files and perform LF normalization
* text=auto
# Custom for Visual Studio
*.cs diff=csharp
这是因为union合并策略对这些文件实际上是危险的，请参阅Merge conflicts in csproj files，了解为什么这并不总是安全且可能不是您想要的。
您通常每次都会遇到合并冲突，但在Visual Studio中它们很容易处理。一个示例案例是向解决方案添加一个新的空项目并提交它，然后让多个团队成员向项目添加不同的文件。
理论上你可以定义一个自定义合并驱动程序来更好地处理xml合并，但我还没有看到其他任何人完成它。
答案 2 :(得分：2)
现在是2020年4月8日，我的选择是将csproj和sln文件标记为binary，仍然试图找到一种坚固的方法，但它仍然不存在。