我如何處理 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做法，但仍然不存在。