分散バージョン管理Git/Mercurial/Bazaar徹底比較：ユカイ、ツーカイ、カイハツ環境！（3）（1/5 ページ）

[岡本隆史，＠IT]

Subversionとは一味違う「分散バージョン管理」とは？

　最近、Linuxをはじめ、Ruby on Rails、MySQL、OpenSolarisなどのオープンソースプロダクトが次々と分散バージョン管理システムを導入し始め、「Git」「Mercurial」「Bazaar」といった、分散バージョン管理システムが注目を浴びています。

　本稿では、バージョン管理ツールのデファクトスタンダードであるSubversion（以下、SVN）と分散バージョン管理システムを比較しながら、メジャーな分散バージョン管理システムであるGit、Mercurial、Bazaarについて紹介していきます。

集中型と分散型

　最初に、集中管理方式（または、集中型）のバージョン管理システムと分散管理方式（または、分散型）のバージョン管理システムの仕組みの違いを見ていきましょう。

　前回の「SubversionとTracでファイル管理の“迷宮”から脱出」では、ソフトウェアのバージョン管理を行うツールとしてSVNを紹介しました。SVNは、サーバ上に中央リポジトリを置き、各開発者はそのサーバからリソースをチェックアウト／コミットすることにより開発を進めていきます。このようなサーバ上でリソースを集中して管理する方式が集中管理方式です。

図1　集中管理方式のバージョン管理システムの仕組み

　集中管理方式では、リソースの履歴の確認、コミット、ブランチの切り替えなどのタイミングでサーバ上のリポジトリへアクセスする必要があります。

　これに対して、分散管理方式では、サーバ上のリポジトリ以外にも各開発者がローカルリポジトリを持ちます。このリポジトリは開発者固有の変更を管理する「プライベートブランチ」となります。

図2　よく見掛ける設計書のフォルダ

　SVNの場合は、サーバ上のリソースをチェックアウトし、変更したリソースをサーバへ直接コミットしていました。分散管理方式の場合は、次のようなワークフローになります。

分散型のワークフロー

1. リポジトリの複製を作成、クローン（clone）
   サーバ上のリポジトリの複製を開発者のマシン上にローカルリポジトリとして作成。SVNでは、チェックアウトにより最新のリソースだけ取得していたが、分散管理方式では中央リポジトリの完全な履歴を含んだリポジトリの複製を取得する
2. コミット（commit）
   SVNでは、サーバへ直接コミットするが、分散管理方式ではローカルリポジトリへコミットする。この時点では、サーバのリポジトリは何の影響も受けない
3. プッシュ／プル（push/pull）
   ローカルのリポジトリの変更内容をサーバ上のリポジトリへ反映するには、プッシュもしくはプルを利用する。プッシュとプルはリポジトリ同期の方向が異なる
   • プッシュ（push）
     ローカルのリポジトリの変更内容をサーバ上のリポジトリへ送信（push）。SVNのコミット相当の操作はプッシュに該当する
   • プル（pull）
     サーバ上のリポジトリから各開発者のリポジトリの変更内容を取得（pull）。各開発者のリポジトリは何らかの方法でリポジトリを公開する必要がある

　ローカルリポジトリを中央リポジトリと同期させるとき（すなわち、SVNにおける更新（update）相当の操作）は、プルを利用して中央リポジトリの更新内容をローカルリポジトリへ取り込みます。

　ここでは、中央リポジトリを利用する例を示しましたが、実際には各リポジトリの関係は対等で、相互のリポジトリで自由にプッシュ／プルができます。

図3　分散バージョン管理システムのリポジトリの関係

分散でも中央リポジトリを経由して利用!!

　分散バージョン管理システムでは、中央リポジトリへ反映されていない他人の変更を自由に自分のローカルリポジトリへ取り込むことができます。例えば、Linuxのカーネルの開発では、個々の開発者がディストリビューション専用のカーネルなどを公開していますが、分散バージョン管理システムを利用しているため、Linux本家の開発のブランチにスムーズに追従できます。

　ただし、そのような使い方をした場合、自分のローカルリポジトリに誰のどの変更を取り込んだか把握していないと、リポジトリの状況が分からなくなるなど弊害が出てくる可能性があります。そのため、通常のソフトウェア開発においては、成果物の共有は中央リポジトリを経由して行うのがいいでしょう。

分散型の7つのメリット

　さて、仕組みはなんとなく分かりましたが、分散バージョン管理システムを利用すると、何がうれしいのでしょうか。SVNとの違いを見ていきましょう。

【1】一時的作業の履歴管理が容易

　分散バージョン管理システムでは、各開発者の作業は、ローカルリポジトリへコミットすることになります。そのため、中央リポジトリに影響を与えることなく各開発者が変更を管理できます。

　集中リポジトリ方式では、開発者がリポジトリにコミットすると、変更内容が開発者間で共有されてしまい、不具合が残っているコードをコミットすると、ほかの開発者の作業に影響を与える場合があります。分散バージョン管理システムでは、ローカルのブランチに対して作業を行い、テストまできちんと終了した作業のまとまりを中央リポジトリへ反映できます。

【2】柔軟なワークフロー

　各開発者の変更をマスターのリポジトリへ取り込むときに、開発者がマスターのリポジトリへ反映する以外に、マスターリポジトリの管理者が各開発者のリポジトリから変更点をプルにより取り込むことができます。この機能により、管理者が確認した変更点だけをマスターリポジトリへ反映できるようになります。

　各開発者が勝手にマスターのリポジトリへコミットするのを避けることができます。例えば、リポジトリ構成を階層化し、各グループのリポジトリ上の変更をリーダーが確認して、上位のリポジトリへプッシュするという使い方ができるのです（図4）。オフショアや外注を利用する場合、発注先のリポジトリの変更を承認して取り込むようにすれば、管理が楽になります。

図4　分散リポジトリによるリポジトリのグループ化

　また、外部のソフトハウスへ外注するシステム開発の場合、ソフトハウスごとにグループリポジトリを構築しておき、リリース時に自社のマスターリポジトリへ差分を取り込むという使い方もできます。ほかにも、個人のホビーでプログラミングする場合はサーバがなくても簡単にバージョン管理できるので、手軽に利用できます。

　このように分散バージョン管理システムは、大規模なソフトウェア開発から、パーソナルな環境まで、さまざまな開発で利用できます。

　次ページでは引き続き、残りのメリットと7つのデメリットも紹介しましょう。