私は通常、バージョン管理に Git を使用して .NET を操作します。私のチームでは並行して作業し、コードをコミットしてアプリケーションに統合することがよくあります。Visual Studio のソリューションとプロジェクト ファイル以外はすべて問題ありません。次の 2 つの方法を見つけました。
- これらのファイルをコミットしないでください。誰もが自分のファイルを持っています
- これらのファイルをバージョンシステムに含める
どちらの方法にも長所と短所がありますが、基本的に中央リポジトリからプルするたびに苦労します。ここで見つかったいくつかの問題は次のとおりです: (括弧内は上記のリストへの参照)
- プロジェクトに他の人のファイルを含めるか（1）、最新のファイルを含めるか（2）
- 異なるアーキテクチャ（x86/x64）で作業する場合は、ファイルを手動で変更する必要があります
.csproj（2） - 参照とNuGetパッケージについても同じ問題が回答されました
等々。使用できる適切なワークフローはありますか?
ベストアンサー1
コミットし.slnて.csprojファイルを保存することが通常はベストプラクティスです（この答え) ですが、マージには注意が必要です。
「.csprojの後にファイルが壊れてしまうのはなぜですかgit rebase?「」。
（下記参照）*.csproj -text merge=union
*.sln -text merge=unionv
あるいは諦めて.csproj地元で再生することもできるこのツイートのように
これらのcsprojファイルを無視するもう1つの理由は、それらが再生成される場合です。この文脈では
イエローブラッド警告する（コメント欄csproj）戦略で使用した場合のファイルとの深刻な競合問題についてmerge=union。
これは記事「csprojファイル内のマージ競合「
だから、VS IDE はプロジェクト ファイル内のファイル パターンをサポートする必要があります（するためにない.csprojそのパターンに適合する新しいファイルを追加する場合は、ファイルを変更します.cs。
Visual Studio が最初に要素をソートすれば、問題が軽減されるだろうと示唆されています
。これは、Visual Studio の要素のソートが明らかに非決定的であることによって引き起こされる偶発的な競合を減らすのに役立ちます。
しかし、マージ競合の問題がなくなるわけではありません。