我如何处理 Git 中的 Visual Studio 解决方案和项目文件？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/21511959/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How I deal with Visual Studio solution and project files in Git?
提问by balanza
I usually work with .NET using Git for versioning. In my team, we work in parallel and we often commit our code to integrate in the application. Everything is fine BUT the Visual Studio's solution and project files. We found two ways:
我通常使用 Git 使用 .NET 进行版本控制。在我的团队中，我们并行工作，我们经常提交代码以集成到应用程序中。一切都很好，但 Visual Studio 的解决方案和项目文件。我们找到了两种方法：
- Never commit those files, everyone has his own
- Include those file in the version system
- 永远不要提交那些文件，每个人都有自己的
- 在版本系统中包含这些文件
Both ways have pros&cons, but basically we struggle every time we pull from central repo. Here some spare issues we found: (in parentesis, the reference to the above list)
两种方式各有利弊，但基本上我们每次从中央回购中提取时都会遇到困难。这里我们发现了一些备用问题：（在括号中，参考上面的列表）
- We have to include other's files in the project (1) or include our newest (2)
- If we work on different architectures (x86/x64) we have to manually change
.csprojfiles (2) - Same issues replied for references and NuGet packages
- 我们必须在项目中包含其他人的文件 (1) 或包含我们最新的 (2)
- 如果我们在不同的架构 (x86/x64) 上工作，我们必须手动更改
.csproj文件 (2) - 为参考和 NuGet 包回复了相同的问题
and so on. Is there a proper workflow I can use?
等等。我可以使用适当的工作流程吗？
回答by VonC
Committing .slnand .csprojfiles is usually the best practice (as in this answer), but merging requires some attention.
See "Why are my .csprojfiles getting messed up after a git rebase?".
提交.sln和.csproj文件通常是最佳实践（如本答案中所示），但合并需要一些注意。
请参阅“为什么我的.csproj文件在 a 之后变得一团糟git rebase？”。
*.csproj -text merge=union*.sln -text merge=unionv
*.csproj -text merge=union*.sln -text merge=unionv
Or you can give up on .csprojand regenerate them locally as in this tweet.
Another reason to ignore those csproj files is if they are regenerated, as in this context
或者你可以放弃并在.csproj本地重新生成它们，如这条推文。
忽略这些 csproj 文件的另一个原因是它们是否重新生成，如在此上下文中
yellowbloodwarns (in the comments) about serious conflict issue with csprojfile when used with the merge=unionstrategy.
That echoes the article "Merge conflicts in csprojfiles".
That is why there is a suggestion for VS IDE should support file patterns in project files(in order to notmodify the .csprojfile if one add a new .csfile that fits that pattern).
Yellowblood警告（在评论中）csproj与该merge=union策略一起使用时文件存在严重冲突问题。
这与“合并csproj文件中的冲突”一文相呼应。
这就是为什么建议 VS IDE 应该支持项目文件中的文件模式（以便在添加适合该模式的新文件时不修改.csproj文件.cs）。
It's been suggested that if Visual Studio sorted its elements first, that would help mitigate the problem.
That helps reduce the incidental conflicts caused by Visual Studio's apparent non-deterministic sort of elements.
But it doesn't make the issue of merge conflicts go away.
有人建议，如果 Visual Studio 首先对其元素进行排序，这将有助于缓解该问题。
这有助于减少由 Visual Studio 明显的非确定性元素引起的偶然冲突。
但这并没有使合并冲突的问题消失。
回答by sme
In our project we check these into version control. We started with the .gitignorefrom githuband a simple .gitattributesfile:
在我们的项目中，我们将这些检查到版本控制中。我们.gitignore从github和一个简单的.gitattributes文件开始：
# Auto detect text files and perform LF normalization
* text=auto
# Custom for Visual Studio
*.cs diff=csharp
This is because the unionmerge strategy can actually be dangerous for these files, see Merge conflicts in csproj filesfor details why this is not always safe and is probably not what you want.
这是因为union合并策略对于这些文件实际上可能是危险的，请参阅csproj 文件中的合并冲突以了解为什么这并不总是安全并且可能不是您想要的详细信息。
You'll generally get merge conflicts every time but they're really easy to handle quickly in Visual Studio. An example case is adding a new empty project to a solution and committing it, then having multiple team members add different files to the project.
您通常每次都会遇到合并冲突，但它们在 Visual Studio 中非常容易快速处理。一个示例案例是向解决方案添加一个新的空项目并提交它，然后让多个团队成员向项目添加不同的文件。
In theory you could have a custom merge driver defined that handles xml merges better, but I haven't seen that done by anyone else yet.
从理论上讲，您可以定义一个自定义合并驱动程序来更好地处理 xml 合并，但我还没有看到其他人做过。
回答by Luke
It's 2020-04-08 and my choice for this is mark csprojand slnfiles as binary, still trying to find a sturdy practice but it's still not existed.
现在是 2020-04-08，我对此的选择是 markcsproj和slnfiles as binary，仍然试图找到一个可靠的做法，但它仍然不存在。
