分散バージョン管理Git/Mercurial/Bazaar徹底比較ユカイ、ツーカイ、カイハツ環境!(3)(5/5 ページ)

» 2009年01月14日 00時00分 公開
[岡本隆史,@IT]
前のページへ 1|2|3|4|5       

分散バージョン管理システムの覇者は?

 コマンドラインで使う分には、達人が使うのでなければ、どのツールも正直あまり代わり映えがしません。一般的な開発者の多くは開発環境として日本語版のWindowsを利用していると思われるので、日本語版のWindows上の環境での状況を中心に各ツールを比較してみます。

表 SVN、Git、Mercurial、Bazaarの機能比較
主な特徴 SVN Git Mercurial Bazaar
最新バージョン(2008年12月現在) 1.5.4 1.6.0.4 1.1 1.10
ライセンス ASL 2 GPL v2 GPL v2 GPL v2
集中型/分散型 集中型 分散型 分散型 分散型
代表的な採用プロジェクト 多数 Linuxカーネル、
Ruby on Rails、
Android、X.org、
Samba、Wine、
Perl 5、そのほか
OpenJDK、
Mozilla、
OpenSolaris、
NetBeans、
Xen、そのほか
Ubuntu、
Mailman、
MySQL、
そのほか
日本語サポート(※比較ポイント【1】)
Windows対応(※比較ポイント【2】)
GUIツールWindows TortoiseSVN、
RapidSVN
TortoiseGit(0.2.0.0)、
git-gui、gitk、qgit
TortoiseHG(0.5)、
Hgtk
bzr-gtk、qbzr
GUIツールLinux RapidSVN qgit、git-gui、gitk Hgtk、hgct bzr-gtk、qbzr
Eclipseサポート(※比較ポイント【3】) Subversive(0.7.4)、
Subclipse(1.4.5)
EGIT
(0.3.1)
Mercurial Eclipes
(1.2)
bzr-eclipse
(1.1.0)
VisualStudioプラグイン AnkhSVN(2.0) × Mercurial SCC plugin for MS Visual Studio
(1.0.1)
×
Tracプラグイン
(プラグインでサポート)

(プラグインでサポート)

(プラグインでサポート)
SVNとの連携
(git-svnをインストールすれば可能)
△(hgsvnをインストールすれば可能。
hgのリポジトリの変更点をSVN側へ反映するにはSVNを利用)
記述言語 C、
Java(SVNKit)
C Python Python
ファイル名変更時の変更履歴の引き継ぎ ×  
Rebase機能 ×
(bzr-rebaseプラグインで対応)
Bisect機能 ×
(Bazaar Bisectプラグインで対応)
Shelve/Unshelve ×
(git stash)

(hgshelveエクステンション)
パッチマネージャ ×
(guilt)

(Mercurial Queue)
×
メール送信可能なパッチ作成 ×
(Patchbombエクステンション)
電子署名付きチェンジセット ×
(タグのみ可能)

(GPGエクステンション)
組み込みサーバ
(git instawebにより可能。
ただしWebブラウザでの閲覧のみ)
○(hg serve) ○(bzr serve)
HTTPプロトコルでの共有方法 WebDAV WebDAV、
git instawebコマンド
CGI、hg
serveコマンド
CGI/WebDAV
(WebDAVはWebDAVプラグインにより対応)
中央リポジトリ利用時のアクセス制御(※比較ポイント【4】) ファイル/ディレクトリ単位で設定可能。
read/write権限の設定まで可能
リポジトリ単位で設定可能 ファイル/ディレクトリ単位で設定可能。
ユーザー別のread/writeの設定は不可
リポジトリ単位で設定可能
無料リポジトリ 多数 GitHub、
assembla、
SouceForge.JP、
CodeRepos
itbucket、
assembla、
ProjectKenai、
freeHg.org
Launchpad

 この表を基に、5つのポイントから比較してみましょう。

比較ポイント【1】日本語化環境での利用

 GitはWindows上のgitコマンドで文字化けしないように利用するために、コラムで紹介したような工夫が必要でした。また、ファイル名に日本語を利用した場合、WindowsとUNIX環境が混在するとファイル名が文字化けします。EGITでも日本語のファイルは正しく扱えません。

 Mercurialではコミットメッセージは特に設定は必要なく、文字化けも起こりません。ただし、Windows/UNIX混在環境ではファイル名が文字化けします。また、Mercurial Eclipseの[History]ビューを見ると文字化けしています。

 Bazaarのみがコミットメッセージ、ファイル名ともにマルチバイト文字の処理をしていて、日本語のファイル名をWindowsやLinuxのようなシステムのエンコーディングが異なる環境間でリポジトリを共有しても正しく扱えます。しかし、Eclipse環境では日本語のファイル名のファイルを正しく扱えませんでした。

 日本語環境での利用はどれも何かしら問題があり、甲乙付け難いですが、bzr本体で完全な処理を行っているBazaarが優勢といったところでしょうか。

比較ポイント【2】Windows環境での利用

 Windows上の環境としては、基本的にすべてCygwinで利用可能です。Cygwin以外でのサポートについては、TortoiseBzrとTortoiseHgを提供しているBazaarとMercurialが一歩抜きんでています。

 GitもTortoiseGitを提供していますが、開発の極めて初期段階であり、現時点では実用的ではありませんでした。Windows専用のビルドツールであるMsysGitを利用するとGit GUIが同梱されてきますが、Windowsシェルとの統合機能はなく、専用クライアントでの利用となります。SVN連携機能は2008年12月の執筆時のバージョンではサポートされていませんでした。

比較ポイント【3】Eclipse上での利用

 Eclipse上の開発環境としては、GitとBazaarはリポジトリ管理下にあるファイルや、リポジトリ上のファイルから変更されたファイルにアイコンが付くなど、Mercurialに比べると優れています。

 セットアップの簡便さとしては、BazaarとMercurialはコマンドラインのツールをインストールし、コマンドラインのコマンドへパスを設定する必要があります。さらに、Bazaarは「xmloutputプラグイン」を追加でインストールする必要がありました。GitはJavaクライアントが組み込まれており、インストールしてすぐに利用できます。

 Mercurialは日本語のコミットメッセージが文字化けし、ファイルの状態がアイコンで表示されないため、BazaarやGitに比べると日本語環境での利用で問題がありそうですが、メニューからのオペレーションは最も豊富です。また、日本語のファイル名を正しく扱えるのはMercurial Eclipseだけです。

 英数字のファイル名のソースコードだけを扱うのであれば導入が楽なGit、日本語のファイル名のファイルを扱うのであればMercurial Eclipseが有利です。

比較ポイント【4】アクセス制御

 GitとBazaarはリポジトリ単位のアクセス制御しか設定できません。Mercurialはディレクトリ/ファイル単位でアクセス制御を設定可能です。しかしながら、アクセスの可否だけでread/writeなどSVNのように細かい設定はできません。

比較ポイント【5】拡張性

 BazaarとMercurialはPythonでモジュールを作成し、プラグイン(エクステンション、機能拡張)としてインストールすることで簡単に機能拡張できます。

 一方、GitはC言語で記述された低レベルコマンドとシェルスクリプトやPerlスクリプトで記述されたハイレベルコマンドから構成されています。これらのコマンドを利用したスクリプトを追加することにより、拡張できるようになっています。アーキテクチャ的にはGitはUNIXの洗練された考え方を受け継いでおり、コマンドをスクリプトで組み合わせて新しい機能を実装します。

そのほか

 先進的な機能はまずGitに実装され、Mercurial、Bazaarが追従しているといった感じです。Rebase機能やBisect機能は少し前まではGitのウリとされてきましたが、現在ではMercurialもBazaarも同等の機能を利用できます。機能的にはどれもどんぐりの背比べと感じました。

いまこそ分散型に移行すべき? Subversionと共存?

 本稿では、メジャーとなりつつある分散バージョン管理システムとしてMercurial、Git、Bazaarを比較紹介してきました。どのツールも甲乙付け難く、どれを使うべきとはいえない状況です。世の中のシェアを見ると、Git>Mercurial>Bazaarというふうに、Gitが最も使われていますが、日本語とWindows環境のサポートがいま一歩です。個人的には、国際化サポートがしっかりしているBazaarをお勧めしたいところですが、将来的にはGit、Mercurialでもこれらの問題は解決されると思われます。

 分散バージョン管理システムを利用した場合でも、成果物を共有するよりどころとして中央リポジトリは必要となります。現時点では、中央リポジトリとしてSVNを利用し、各自の作業を行うローカルリポジトリに分散バージョン管理システムを利用するのがベストだと筆者は考えています。各自のローカルリポジトリを管理するツールを変更するのであれば、中央リポジトリへは影響を与えないので、後々ツールを変更してもオーバーヘッドにはなりません。

 新しくツールを覚えたくない開発者はSVNのクライアントを従来どおり利用できます。ロック処理やサーバの細かいアクセス制御などのSVNのメリットを得ながら、分散バージョン管理システムが有利な場面では、分散バージョン管理システムを併用し、まずは適用しやすい場面や開発者から導入を始めてみてはいかがでしょうか。

 最後になりますが、本稿を執筆するに当たり、Debianで日々Gitを使っている上川純一氏にご協力をいただきました。上川氏にご協力いただいたとはいえ、本稿に誤りがある場合は責任の一切は筆者と@IT編集部にありますのでご了承ください。


「ユカイ、ツーカイ、カイハツ環境!」バックナンバー
前のページへ 1|2|3|4|5       

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。