Git と TFS との比較と使用感

.NET 系の開発者だと、ソース管理は TFS (Team Foundation Server) を使っていることが多いと思う。化石みたいな現場だと VSS (Visual SourceSafe) が未だに現役であるかもしれない。あとは Subversion も使っている現場は多い。

個人的な結論としては、Visual Studio を使っているなら、TFS が一番シンプルだし、わかりやすいと思う。アジャイル開発におけるタスク管理等をしたいなら、逆にこれ以外は考えられない。

そんななか、Git を採用している現場があったので 3 ヶ月ほど使ってみた感想をまとめる。間違って理解している部分や、現場によってはもっとスマートに使っていることもあるだろう。
だから、もし VSS から Git へ変更しようと検討してるのならこういう声もあるということの情報共有のつもりでまとめている。

Git (ギット) の特性

Git を理解するうえで、はじめに上げたバージョン管理システムと大きく違うのが、Git は分散型バージョン管理システムである点であり、この理解がないと意味が全くわからない。
全員が同じ場所にチェックインやチェックアウトしていく TFS などと違い、まず、リモートリポジトリ、ローカルリポジトリという概念があることを理解する。リポジトリとは、ソース等を保管する場所みたいな概念である。

コミットとプッシュの違いを理解する

集中型のバージョン管理システムでは、コミット（チェックイン）を行うと、それが最新としてアップロードされるわけだが、Git の場合はコミットとはあくまでローカルにある「自分用」のリポジトリを更新する行為である。そのため、コミットしまくっても他の人には影響を及ぼさない。
他の人にも自分の修正箇所を取得させたい場合には、リモートリポジトリに「プッシュ」しなければならない。

差分は自分で解決する

私は SourceTree というソフトを使っているのだが、差分（競合という）が出た場合は自分で解決しなければならない（オプションの Diff から設定すれば WinMerge も使える）。
ソースコードをきれいにしてからみんなが触るところにアップしてね！
という考え方だ。
TFS の場合は、マージが非常に楽であるので、このコストはかなり大きいと思う。

作業の流れ

ブランチを見て、自分のローカルリポジトリが最新であるか確認。リモートリポジトリに新しいコミットがあった場合は「プル」する。
修正。
コミット（ローカルリポジトリに対して）。
プル（競合が発生した場合はマージ）。
プッシュ

こんな感じ。TFS だと、

最新の取得。
修正。
チェックイン（基本的に最新のものと自動マージ。競合があった場合はマージツールが起動してくるのでソースを見ながらマージ）

という感じ。

Git を使うべき現場

個人的な印象から、こんな現場では TFS よりも便利なのかな、と思った。

外注が多い現場

社内で開発というより、外に実装等を多く出している現場。最終的にとりまとめてソースをマージして、ソースを保守してく要因が必要だが、リモートリポジトリを汚されずにきれいなソースを保管することができる。

多くのブランチを切りたいシステム

DLL を分けていたり、バージョン違いをたくさんリリースしたい場合は TFS より有効だと思われる。ただ、リモートリポジトリの保守は必須。

Git を使うべきではない現場

以下のような現場では、分散型ソース管理システムを使う意味があまりないと思う。

少数の開発担当者（実装者）で開発する現場。
リリースするバージョンが多岐にわたらない。

結論

TFS は Microsoft らしい合理的なバージョン管理システム。
マスターのソースコードを美しく保守したいなら Git。

といった印象。最終的には好みでいいのだろう。

しかし、Git を使いこなすためには、Git マスターが必要だと思うし、教育とルールづくりをメンバーで守れる現場でないと、競合が出た時にかかるコスト（マージのコスト）が大きすぎる。ルール無視で使うと、ソースの消失やマージミスが多発する（多発した）。

Remember The Time