web-dev-qa-db-ja.com

GitでVisual Studioソリューションとプロジェクトファイルを処理するにはどうすればよいですか？

私は通常、バージョン管理にGitを使用して.NETで作業します。私のチームでは、並行して作業しており、アプリケーションに統合するためにコードをコミットすることがよくあります。すべてが問題ありませんが、Visual Studioのソリューションとプロジェクトファイルです。 2つの方法が見つかりました。

  1. それらのファイルをコミットしないでください、誰もが自分のものを持っています
  2. これらのファイルをバージョンシステムに含める

どちらの方法にも長所と短所がありますが、基本的には中央レポからプルするたびに苦労します。ここで私たちが見つけたいくつかのスペアの問題：（括弧内は上記のリストへの参照）

  • プロジェクトに他のファイルを含める（1）か、最新のものを含める（2）
  • 異なるアーキテクチャ（x86/x64）で作業する場合、.csprojファイルを手動で変更する必要があります（2）
  • リファレンスとNuGetパッケージについて同じ問題が返信されました

等々。 使用できる適切なワークフローはありますか？

c#gitvisual-studioworkflowversioning
21
balanza

_.sln_および_.csproj_ファイルをコミットすることは通常ベストプラクティスですが（ この回答 のように）、マージには注意が必要です。
「 _.csproj_の後で私の_git rebase_ファイルがめちゃくちゃになるのはなぜですか 」を参照してください。

_*.csproj -text merge=union_ （下記参照）
_*.sln -text merge=union_ v

または、_.csproj_をあきらめてローカルで再生成することもできます このツイートのように 。
それらのcsprojファイルを無視するもう1つの理由は、それらが このコンテキストで として再生成されるかどうかです。

yellowblood は、_merge=union_戦略と共に使用した場合のcsprojファイルとの深刻な競合問題について警告（ コメント内 ）します。
これは、記事「 csprojファイルでのマージの競合 」を反映しています。
そのため、 VSの提案IDEプロジェクトファイルのファイルパターンをサポートする必要があります （notそのパターンに適合する新しい_.csproj_ファイルを追加する場合、_.cs_ファイルを変更します）。

Visual Studioがその要素を最初にソートした場合、問題の緩和に役立つことが示唆されています。
それは、Visual Studioの明らかに非決定的な種類の要素によって引き起こされる偶発的な競合を減らすのに役立ちます。
しかし、マージの競合の問題がなくなるわけではありません。

16
VonC

私たちのプロジェクトでは、これらをバージョン管理にチェックインします。 .gitignore from github および単純な.gitattributesファイル：

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

# Custom for Visual Studio
*.cs diff=csharp

これは、unionマージ戦略がこれらのファイルに対して実際に危険である可能性があるためです。これが常に安全であるとは限らず、おそらく望んでいない理由の詳細については、 csprojファイルでのマージの競合 を参照してください。

通常、毎回マージの競合が発生しますが、Visual Studioですばやく簡単に処理できます。例として、新しい空のプロジェクトをソリューションに追加してコミットし、複数のチームメンバーがプロジェクトに異なるファイルを追加するようにします。

理論的には、xmlマージをより適切に処理するカスタムマージドライバーを定義することもできますが、他の人がそれを実行したことはまだありません。

6
sme