我如何处理 Git 中的 Visual Studio 解决方案和项目文件？

Question

我通常使用 Git 使用 .NET 进行版本控制。 在我的团队中，我们并行工作，我们经常提交代码以集成到应用程序中。 一切都很好，但 Visual Studio 的解决方案和项目文件。 我们找到了两种方法：

1. 永远不要提交那些文件，每个人都有自己的
2. 在版本系统中包含这些文件

两种方式各有利弊，但基本上每次我们从中央回购中提取时，我们都会遇到困难。 这里我们发现了一些备用问题：（在括号中，参考上面的列表）

• 我们必须在项目中包含其他人的文件 (1) 或包含我们最新的 (2)
• 如果我们在不同的架构 (x86/x64) 上工作，我们必须手动更改.csproj文件 (2)
• 为引用和 NuGet 包回复了相同的问题

等等。 我可以使用适当的工作流程吗？

Answer 1

提交.sln和.csproj文件通常是最佳实践（如本答案所示），但合并需要一些注意。
请参阅“为什么我的.csproj文件在git rebase后变得混乱？ ”。

*.csproj -text merge=union （见下文）
*.sln -text merge=union v

或者你可以放弃.csproj并像这条推文一样在本地重新生成它们。
忽略这些 csproj 文件的另一个原因是它们是否重新生成，如在此上下文中

当与merge=union策略一起使用时， yellowblood警告（ 在评论中）关于csproj文件的严重冲突问题。
这与“ 合并csproj文件中的冲突”一文相呼应。
这就是为什么建议 VS IDE 应该支持项目文件中的文件模式（为了在添加适合该模式的新.cs文件时不修改.csproj文件）。

有人建议，如果 Visual Studio 首先对其元素进行排序，这将有助于缓解该问题。
这有助于减少由 Visual Studio 明显的非确定性元素引起的偶然冲突。
但这并没有使合并冲突的问题消失。

Answer 2

在我们的项目中，我们将这些检查到版本控制中。 我们从github的.gitignore和一个简单的.gitattributes文件开始：

# Auto detect text files and perform LF normalization
* text=auto

# Custom for Visual Studio
*.cs diff=csharp

这是因为union合并策略对于这些文件实际上可能是危险的，请参阅csproj 文件中的合并冲突以了解为什么这并不总是安全并且可能不是您想要的详细信息。

您通常每次都会遇到合并冲突，但它们在 Visual Studio 中非常容易快速处理。 一个示例案例是向解决方案添加一个新的空项目并提交它，然后让多个团队成员向项目添加不同的文件。

从理论上讲，您可以定义一个自定义合并驱动程序来更好地处理 xml 合并，但我还没有看到其他人这样做过。

Answer 3

现在是 2020 年 4 月 8 日，我对此的选择是将csproj和sln文件标记为binary ，仍在尝试找到csproj做法，但仍然不存在。