VSS ユーザーがゆるやかに Git に移行するためのゆるいガイド

サポートライフサイクルはこちら:

そして前から言い続けておりますが、VSS はサーバー製品ではなく、デスクトップ製品です。なので、チームで開発するうえではアーキテクチャ的にも適切かどうかは各現場でしっかりと検討しないといけないです。

VSS 使いの方々が、移行すべき選択

「VSS を使い続けない」と判断をした場合には、いくつかの選択肢が残されています。 大別すると、以下になります。

• 中央集中型のバージョン管理システム
  • Subversion (SVN), TFS (Team Foundation Server), ClearCase, Perforce, など
• 分散型のバージョン管理システム (DVCS)
  • Git, Mercurial (Hg), など

バージョン管理システム (VCS) には、この２つの選択肢が基本的にあります。

VSS はこのうちの、「中央集中型の VCS」に比較的近いです (単一ファイルに共有フォルダでアクセスするのが VSS の基本なので、一概にコレといえないというのが個人的な見解です)。

ここで、選択肢として、TFS (現 Azure DevOps Server)を取り上げてみましょう。TFS は、上記では、中央集中管理にて紹介していますが、VCS を Git にすることもできます。すなわち、TFS ならば、中央集中にも、分散にもできるわけです。

また、TFS は、MSDN サブスクリプション会員は、サーバーライセンスもクライアントアクセスライセンス (CAL) も特典として付与されていますので、VSS も TFS も追加費用なしで使うことができるので選択肢の考慮として記憶しておくべきです。

ただし、TFS は VCS だけを提供するものではありませんので、そこも検討材料とすべきです。VCS だけでいいのか、より包括的な ALM の世界観を検討したいのか、それによって分岐点となります。個人的には、VCS だけを使うことに疑問をもっていますし、そもそも VCS を開発現場で使いこなすのは、難しいです。

難しい理由は、今までもこのブログや講演でも触れていますので、今回は、割愛します。知りたい場合は、このブログと ITmedia オルタナティブブログの方を探してみてください。

今回は、VSS からの移行選択として、 Git を選択した場合について以下に、アバウトに、ゆるく、その違いを綴っていきます。あくまで VSS ユーザーの方向けの記事ですので、Git をしっかりと使いたい方向けではないので、そのあたりのツッコミなどはご遠慮くださいw

DVCS の仕組み

ここでは、前提として、DVCS がどのような仕組みなのかアバウトにゆるく図示しておきます。

VSS では、ファイル共有されたファイルに対して、アクセスし、「ファイルの取得」をするとクライアントマシン上にソースコードを取得でき、「チェックアウト」でファイルを編集を宣言しつつ、ファイルをロックします。「チェックイン」でファイルに対する変更を共有フォルダ上のファイルに反映をさせます。

中央集中型の VCS では、データベースリポジトリが用意されていて、サーバーとクライアントのコミュニケーションも HTTP などを使って軽量に行います。VCS によって操作は微妙に異なりますが、おおざっぱにいうと、Subversion などでは、ファイルを取得することを「チェックアウト」といい、編集したファイルをリポジトリに反映することを「コミット」と言います。

DVCS の場合は、開発者のマシン (クライアント) にも、リポジトリが存在することになります。ファイルを取得するには、まず、クライアントにリポジトリのクローンを作る必要があります。また、目的のブランチに切り替えることを「チェックアウト」といいます。

ファイルを編集したら、それを反映するために「コミット」を行います (厳密には、インデックスにステージングする操作も必要ですが、ここでは簡略化のために割愛w)。ここで、注意しなければならないのは、DVCS では、「コミット」しても、クライアントのリポジトリに反映されるだけで、それがサーバーのリポジトリには反映されないということです。

サーバーサイドのリポジトリに反映するには、「プッシュ」という操作を行う必要があります。同様に他の開発者による変更をクライアントのリポジトリに反映するには、「プル」という操作を行う必要があります。 と、書いているとなんだか難しいそうに感じてくるのかなと思いますので、この辺でやめておきますw ここまででおさえておいていただきたいのは、リポジトリの所在や構成が異なっているんだということです。

これらを煩雑だと思ってしまう方は、DVCS の基本を他のリソース (あとで紹介もします) でおさえておいていただきたいですのが、後述の DVCS クライアントツールがある程度よしなにやってくれますので、ひるまないでください。

Git と Git リポジトリ管理

Git は、オープンソースの DVCS です。そのまま使うこともできますが、「裸」のままではいろいろとチームで使うには難しいので、 Git リポジトリ管理の仕組みとともに導入することが多いです。代表例を挙げてると以下です。

• ホスティング型 SaaS などクラウドにホストされた Git リポジトリです。Git の良さだけでなく、Pull Request や Issue Tracking の仕組みなどチームでコラボレーションするうえでの基本的な機能を備えているものが多くあります。 代表例は、以下。 それぞれ、特長があることと、無料枠でどこまでできるのかといったところに差異があります。
  • GitHub | 公開リポジトリが無料, リポジトリ数で課金
  • GitLab | OSS
  • Bitbucket | 5ユーザーまで無料, 公開/プライベート リポジトリも無料, ユーザー数で課金, Mercurial も選択可能
  • Visual Studio Team Services| 5ユーザーまで無料, プライベートリポジトリのみ提供, ユーザー数で課金, ※VCS で Git を選択する必要がある
• 自社運用型 自社のイントラネット内のサーバー環境に Git のリポジトリを構築する形式です。こちらも Git の良さだけでなく、様々な付加機能が付いています。
  • Bitbucket Server (a.k.a. Stash) | 有償製品, 無料評価可能, 10ユーザーで$10から提供 (25ユーザーで$1,800)
  • GitHub Enterprise | 有償製品, 無料評価可能, 20ユーザーで$5,000から提供
  • TFS | 有償製品, 無料評価可能, 無料のエディションあり, ※VCS で Git を選択する必要がある
  • GitLab | OSS

Git クライアント

さて、ここまでは、Git のリポジトリ、サーバー環境について見てきましたが、ここからは、Git のクライアント環境を見てきましょう。いろいろあるので、挙げていたらきりがないので、ここでは代表的なものを挙げています。 前提として、「VSS ユーザー ≒ 開発マシンが Windows」として見てきましょう。

• Git for Windows Git を Windows で利用するには、こちらが定番になります。コマンドラインツール、 GUI ツール、Windows エクスプローラー統合が使えるようになります。
• SourceTree Atlassian が無料提供している DVCS のクライアントツールです。多くの方が使っていますし、Git 書籍でも定番ツールとして操作方法が紹介されています。今回は、こちらを使った感じで後述していきます。
• Visual Studio 2013 チームエクスプローラー/ Visual Studio 2012 Tools for Git Visual Studio には、Git クライアントが組み込まれています。

VSS ユーザーだと、おそらく VSS エクスプローラのように使いたいでしょうから、SourceTree をお勧めします。

SourceTree を VSS ぽっく使う

では、SourceTree を使って VSS エクスプローラっぽく、そして、できるだけ DVCS っぽくない使い方をするステップを見ていきましょう。くどいようですが、あくまで VSS ユーザーが親しみやすく Git を知るきっかけの一つとしていただくことを目的としていますので、DVCS らしさを消していますが、それが本筋ではありません。

はい。これが SourceTree for Windows の画面ショットです。え？エクスプローラーでないじゃんって？そうです。ソースコードが見渡せるわけではありません。VSS エクスプローラのように見たければ、Git for Windows の Windows エクスプローラー統合による画面を見た方が親しみやすいでしょう。

ファイルを取得

ファイルを取得に相当するのは、「クローンを作成する」もしくは、「チェックアウト」になります。

厳密には、「クローンを作成する」は、ローカルリポジトリとしてサーバーサイドのリポジトリを複製することになります。また、「チェックアウト」は、どのブランチで作業するのか、切り替えることをさします。

チェックアウト / ロック

ここで重要としたいのは、ここのファイルを (VSS での) チェックアウト/ロック するということを忘れるということです。言い換えると、どのファイルを変更したいのか/変更したのかを他のものに通知する。排他制御するということ自体が、DVCS の場合はあまり意味をなしません。なぜならば、クライアントにローカルのリポジトリを持っているからです。したがって、基本的には自由にファイルを変更していくことができます。

次に大切なのは、どのファイルを変更したのかを正しく知ることです。VSS はアトミックなチェックインが提供されていないので、各ファイルの変更を VSS エクスプローラで各自で把握しながら、個々のファイルをチェックインすることが求められます。Git では、変更されたファイルを識別するとともに、どの変更を今回のコミットに含めるかを選別することができます。インデックスにステージングするという作業です。

SourceTree ではこのように表示されます。「作業ツリーのファイル」には、変更があったファイルが一覧で表示されます。「Index にステージしたファイル」というのが、コミット対象となる (コミットの予約) ファイルが一覧されます。

上図では、まだコミット対象となるファイルがないということになります。各ファイルを選択すると、それぞれの変更前と変更後 (現状) との差分を見ることができます。 「作業ツリーのファイル」にあるチェックボックスをチェックするとすべてのファイルを Index にステージすることができます。個別のファイルのチェックボックスをチェックすれば、個々のファイルごとに同様のことを行うことができます。

ここまでの流れは、VSS でいうと、「VSS エクスプローラで、チェックインしたいファイルを選択した」に相当します。

チェックイン

VSS での「チェックイン」は、DVCS では、2段階必要となります。前述のとおり、DVCS では、ローカルのリポジトリとリモートのサーバーサイドのリポジトリがあるからです。

Subversion や Git では、VSS のチェックアウトに相当する操作は、「コミット」と呼びますが、DVCS を VSS っぽくやるならば、DVCS では、「コミット」と「プッシュ」を同時に行ってしまうことになります。 「コミット」だけを行うと、ローカルのリポジトリにだけ反映され、リモートのリポジトリには、反映されません。VSS ユーザーはこのあたりを注意しておく必要があります。なので、DVCS っぽさをなくして使うなら、「コミット＆プッシュ」ですw SourceTree には、この「コミット＆プッシュ」ができるようになっています。

「変更を xxxxxxxxxxxxxx にすぐにプッシュする」というチェックボックスがあります。この設定は、オプションで既定する/しないを制御できます。VSS ユーザーの方は、既定にしておくとよいでしょう。

 

他の変更の反映

VSS ユーザーがもうひとつ気を付けないといけないのが、他の人が (同一ブランチ) で変更を行った場合のケアです。この操作は、「プル」という方法で行うのですが、SourceTree では、プルすべき件数を「プル」アイコンに示してくれますので、それがあったら、「プル」するでいいでしょう。 となっているアイコンが、 というように、変更があることがわかります。どのファイルがどう変更されたのかも、事前に把握することができます。

となっていたバージョンのツリー（コミット ツリー）が、

というように、なります。ファイル内容も差分で表示されます。

 

操作まとめ

操作をまとめると以下になります。

VSS	Git with SourceTree
ファイルを取得する	クローン / チェックアウト
チェックアウト / ロック	n/a
(変更されたファイルを選択する)	Index にステージング
チェックイン	コミット & プッシュ
(他の変更を反映) ファイルリストの更新	プル

Git をきとんと知りたい方向けの情報リソース

今回は、VSS ユーザーにわかりやすくという思いで、思い付きで書いてみましたが、かなりの分量になってしまい後悔していますw Git の良さを思いっきり省いた運用で提示していますが、Git や DVCS については以下の情報リソースなどを参考にしていただき、ぜひそのメリットを享受した使い方をしてみてください。