最初のエントリでは、任意のバージョン管理システムの基本である diff と patch について取り上げました。diff と patch について確認した後は、バージョン管理システムについて見てみましょう。皆さんの多くは Subversion (SVN)、CVS、そして Perforce などの 集中型バージョン管理システム に馴染みがあるかも知れません。一方で、最初から Git や Mercurial などの 分散型バージョン管理システム の世界に飛び込んだ人もいるかもしれません。これ以外にも多くの集中型や分散型バージョン管理システムが存在しており、それぞれにメリットとデメリットがあります。
集中型バージョン管理
バージョン管理システムは数多く存在します。多くの場合、"集中型" と "分散型" という 2 つのグループに分類されます。
集中型バージョン管理システムは、プロジェクトの単一の "中心" コピーがどこかに (おそらくサーバー上に) 存在するという考えに基づいています。プログラマーはこの中心コピーに変更を "コミット" することになります。
変更の "コミット" は、単純に中央システムにその変更を記録することを意味します。その後、他のプログラマーはこの変更を見ることができます。また、変更を取得することもできます。バージョン管理ツールは、変更されたすべてのファイルのコンテンツを自動的に更新します。
最近のバージョン管理システムの多くは、"チェンジセット" を扱います。これは、一塊として扱うべき変更のグループ (場合により多くのファイルへの変更) です。たとえば、C ヘッダー ファイルへの変更とそれに関連する .c ファイルは常に一緒に扱うべきです。
集中型バージョン管理は、前回の投稿の「バージョン管理とは」で説明した問題を解決します。プログラマーは、ファイルの大量のコピーを自身のハード ドライブ上に手動で保存する必要はなくなります。バージョン管理ツールは中心コピーと通信し、必要となる任意のバージョンをその場で取得できるからです。
皆さんが耳にしたり使用したことのある最も一般的な集中型バージョン管理システムは、CVS、Subversion (または SVN) そして Perforce でしょう。
典型的な集中型バージョン管理のワークフロー
集中型バージョン管理システムを使用して作業している場合、プロジェクトにおける新機能の追加やバグの修正に関するワークフローは通常、以下のようになります。
- 他のユーザーが行った任意の変更を中央サーバーから取得する。
- 変更を行い、そのコードが正しく動作することを確認する。
- 中央サーバーに変更をコミットすることにより、他のプログラマーはその変更を見ることができる。
分散型バージョン管理
過去 5 年程度の間に、"分散型" バージョン管理システム (省略形は DVCS) と呼ばれる新しい種類のツールが出現しました。その中で最も人気のツールは Mercurial、Git、そしてBazaar の 3 つです。
これらのシステムでは、プロジェクトのファイルの全バージョンを保管するために中央サーバーを必要としません。その代わりに、各開発者はレポジトリのコピーを "クローン" し、自身のハード ドライブ上にそのプロジェクトの 完全な 履歴を持ちます。このコピー (または "クローン") には、オリジナルのすべてのメタデータが含まれています。
この方法は無駄が多いように思えるかもしれませんが、実際のところ問題はありません。プログラミング プロジェクトの多くは、主にテキスト形式のファイルで構成されています (画像が数点含まれる場合もありますが)。ディスク スペースへの負荷は少ないので、ファイルのコピーを多く保存してもハード ドライブの空き容量が著しく減少することはありません。また、最近のシステムはファイルを圧縮するため、スペースの消費はより少なくなっています。
レポジトリから新しい変更を取得する操作は、通常 "プル" と呼ばれ、自分の変更をレポジトリに移動する操作は "プッシュ" と呼ばれます。いずれの場合でも、単一ファイルの差分ではなくチェンジセットを移動します (ファイル グループへの変更を一塊として)。
分散型バージョン管理システムに関するよくある誤解の 1 つが、中央プロジェクト レポジトリが存在しないというものです。これは単なる間違いです。「プロジェクトのこのコピーは信頼できるものである」と宣言することを阻むものはありません。つまり、使用するツールが中央レポジトリを要求する代わりに、それがオプションとなり純粋にソーシャルな問題になっただけです。
集中型バージョン管理と比較してのメリット
レポジトリ全体をクローンするという操作は、集中型システムと比較して分散型バージョン管理ツールにいくつかのメリットをもたらします。
- チェンジセットのプッシュやプル以外の操作の実行は非常に高速です。理由は、ツールがアクセスする必要があるのはリモート サーバーではなくハード ドライブだからです。
- 誰の目にもさらされることなく、新しいチェンジセットのコミットをローカルで行えます。チェンジセットのグループの準備が完了したら、それらをすべて一度にプッシュできます。
- プッシュとプル以外のすべての操作はインターネット接続なしに行えます。したがって、飛行機の中でも作業できます。また、複数のバグ修正を 1 つの巨大なチェンジセットとしてコミットする必要はありません。
- プログラマーはプロジェクト レポジトリの完全なコピーをそれぞれ持っているため、変更を同時に 1 人か 2 人のプログラマーと共有してフィードバックを得てから、その変更を全員に公開できます。
集中型バージョン管理と比較してのデメリット
正直なところ、分散型バージョン管理システムを使用することは、集中型バージョン管理システムの場合に比べてデメリットはほとんどありません。分散型システムは単一の "中央" レポジトリを持つことを阻むものではなく、さらなるオプションを提供します。
分散型システムの使用には、2 つだけ大きな固有のデメリットがあります。
- 簡単に圧縮できない巨大なバイナリ ファイルがプロジェクトに多く含まれている場合、これらのファイルの全バージョンの保管に必要な容量は瞬く間に増えていくことになります。
- プロジェクトの履歴が非常に大量 (50,000 チェンジセット以上) である場合、履歴全体のダウンロードに要する時間とディスク容量は非現実的です。
最近の分散型バージョン管理システムの製作者と協力者はこうした問題の解決に努めていますが、現時点ではこれを解決できる組み込みの機能はありません。
結論
バージョン管理システムは、"コード ファイルの複数のバージョンの保管と共有" というプログラマーが直面する問題の解決を主眼に置いています。あなたがプログラマーで、バージョン管理を何も使用していない場合、今すぐ使い始めることをお勧めします。作業がずっと楽になります。
次の話題
基本的なことに触れましたので、分散型バージョン管理システムについてもう少し深く掘り下げてみましょう。なぜ Git を選択するのか? Mercurial を選択する理由は? 次回以降のエントリでこれらの疑問にお答えします。
(翻訳協力: ゴーツーグループ株式会社)
*本ブログは Atlassian Blogs を翻訳したものです。本文中の日時などは投稿当時のものですのでご了承ください。
*原文 : 2012 年 2 月 14 日投稿 “What is Version Control: Centralized vs. DVCS“