Visual StudioでGitを使う

2013年1月、マイクロソフトは、すべてのALM製品でGitを完全にサポートすることを発表しました。また、Gitソースコントロールの統合を可能にするVisual Studio 2012用のプラグインを公開しました4。

また、Git Extensionsと呼ばれるプロジェクトでは、Visual Studio 2005、2008、2010、2012用のアドインと、Windows Explorerとの統合が行われています。このプロジェクトは定期的に更新されており、いくつかのプロジェクトで使用してみたところ、非常に便利であることがわかりました。

また、「Git Source Control Provider」2という選択肢もあります。

私は、Protocol BuffersをC#に移植する際に、Visual Studioと共にGitを使用しています。GUIは使っていません。Visual Studioと同様にコマンドラインを開いています。

ほとんどの場合、それは問題ありません。唯一の問題は、ファイルの名前を変更したいときです。GitもVisual Studioも、どちらかというと*自分が名前を変更したいと思っています。しかし、Visual Studioでファイル名を変更するのが良い方法だと思います。これまでは少し面倒でしたが、Git側では内容がほとんど同じであることに気づくことができるので、実際にはかなりシームレスになるはずだと聞いています。(完全に同じというわけではありませんが、クラスの名前を変更するときにファイルの名前も変更する傾向があります）。)

でも、基本的には問題なく動作します。私はGitの初心者ですが、必要なことはすべて行うことができます。binとobj、そして*.userのためのgit ignoreファイルがあることを確認してください。

ツリー全体を扱うGitは、ファイルベースのソース管理ツールや、チェックアウト・編集・コミットのパターンに従うソース管理ツールに比べて、IDEとの統合による恩恵が少ないと感じています。もちろん、ボタンをクリックして履歴を確認するのが良い場合もありますが、私はあまりそれを必要としません。

本当にやるべきことは、共有リポジトリに入れてはいけないものを .gitignore ファイルにまとめておくことです。私が使っているファイルにはたいてい次のようなものが含まれています。

*.vcproj.*.user
*.ncb
*.aps
*.suo

しかし、これはC++に偏っていて、クラスウィザードスタイルの機能はほとんど使っていません。

私の使用パターンは以下のようなものです。

1.Visual Studioでコード、コード、コード。

2.2. 満足したら(常識的な中間点として)コードをコミットし、Gitに切り替え、変更をステージングし、差分をレビューする。明らかに間違っているところがあれば、Visual Studioに戻って修正し、そうでなければコミットする。

マージやブランチ、リベースなどの派手なSCM作業は、Gitのコマンドプロンプトで簡単に行えます。Visual Studio は、通常は自分の下での変更に満足しています。ただし、プロジェクトファイルを大幅に変更した場合には、プロジェクトの再読み込みが必要になることもあります。

私はGitの便利さが、IDEと完全に統合されていないことによる些細な不便さを上回っていると感じていますが、それはある程度、好みの問題でもあります。