この記事は Steve Losh によるゲストブログで、チームが (分散) バージョン管理システムとして Mercurial を選択する主要な理由について焦点を当てています。 分散バージョン管理についての Steve の素晴らしい取り組みについては、彼のプロジェクトをチェックしてください。あるいは、彼の Bitbucket アカウントを直接見てみたり、たくさんあるプロジェクトの中から一つをフォークしてみてください。
前回の記事では、バージョン管理の歴史とそれが良い理由、そして集中型システムよりも分散管理システムが良い理由について説明しました。
今日広く使われている分散バージョン管理システムが2つあります。Mercurial (Hg) と Git です。 Git あるいは Hg を選択するたくさんの理由 (そして意見) があります。このブログシリーズの今回の記事と次の記事により、その理由のいくつかを説明していきます。
合理的なコマンド ライン インタフェース
コマンドラインインタフェースは、新しいバージョン管理システムを使用する時に、多くのプログラマーが最初に目にするものです。Mercurial の CLI は、機能を十分に備えており、安定していて、美しいものです。これは “各コマンドは一つのことだけをとてもうまく実行すべきだ” という UNIX 哲学に従っています。
Git の CLI は非常に柔軟性のある設計になっています。各コマンドには、その動作を変更できる多くのオプションがあります。入力は少なくなりますが、様々なオプションとそれぞれがどう相互作用するのかを全て覚える必要があります。 Git のドキュメントはオプション間の全ての相互作用を詳細に記述しなければなりませんので、冗長になり、さっと見ることは難しくなります。
Mercurial のシンプルなアプローチは、ドキュメントを洗練された、簡潔なものにします。hg help を用いて、探しているものを簡単に見つけられます。ドキュメントを見ている時間を短縮し、コーディングにすぐに戻れます。”賢さ” よりも明瞭さを優先し、使いやすいツールになっています。
Mercurial は、より一般的なコマンドのエイリアスのいくつかをあらかじめ予測し、それらが動作するようになっているので便利です。 例えば、hg rename コマンドは、hg move あるいは hg mv でもまた動作します。Git では git mv コマンドだけです。もし必要であれば git move エイリアスを独自に作成できますが、それは Git の CLI を快適に使うためにもう1ステップが必要であることを意味します。Mercurial はデフォルト設定で快適に使えます。
Mercurial の CLI はまた Subversion のものにとても似ているので、その2つのツール間の移行を容易にしています。 よく使うコマンドのいくつかを比較します。Subversion のものと同じである Mercurial/Git コマンドは太字で表示しています。
Subversion (SVN) |
Mercurial (Hg) |
Git |
|---|---|---|
| svn add | hg add | git add |
| svn blame | hg blame | git blame |
| svn cat | hg cat | git show |
| svn checkout | hg clone | git clone |
| svn commit | hg commit ; hg push | git commit -a ; git push |
| svn delete/remove | hg remove | git rm |
| svn diff | hg diff | git diff, git diff –cached |
| svn help | hg help | git help |
| svn log | hg log | git log |
| svn revert | hg revert | git checkout -f |
| svn status | hg status | git status |
| svn update | hg pull –update | git pull |
| svn move/rename | hg move/rename | git mv |
ここで見たように、Git は、Subversion ユーザーにその CLI に早く慣れてもらうようにするということをあまり考慮していません。 新しいコマンドを入力するために指を再度トレーニングすることによりこの問題を回避することはできますが、それでもシステムを移行する上での障害の一つになるでしょう。その上、Subversion ユーザーにとってフレンドリーで、かつ、強力で美しいインターフェースをもった Mercurial があるので、Git がなくても問題はありません。
履歴が安全な Mercurial
Mercurial の哲学は、 “履歴は永久的で神聖である” ということです。Mercurial のコアには、履歴を変更できるコマンドがたった一つだけあります。hg rollback です。このコマンドは直前のプルやコミットを “取り消し” ますが、それより前のものには一切触れません。
Git は、その一方で、プロジェクトの履歴を素早く、ゆるく操作できます。git rebase -interactive のようなコマンドにより、履歴を書き換えることができ、そしてデータを削除することもできます。
はい、git rebase -interactive により破壊したチェンジセットは、git reflog を用いて発見することができます。しかし、変更を行ってから 1 ヶ月以上経過していると、チェンジセットは失われています。(Git はチェンジセットに対して 1 ヶ月後に “ガーベッジコレクション” を行います。)
コアに破壊的なコマンドを持っているということは、ユーザーがよく理解していないコマンドを実行することによって、墓穴を掘る可能性がより高いということを意味します。
Mercurial において履歴を書き換える必要がある時のために、collapse、histedit、MQ といったエクステンションがあります。この機能をコアの外においておくことにより、準備が整う前に新しいユーザーが誤って使用してしまうことを防ぎます。
これらのエクステンションのほとんどはまた、破壊した全てのチェンジセットをバンドルに永久的にバックアップします。これらのバンドルはガーベッジコレクションされないので、バージョン管理システムがデータを削除してしまう心配をする必要はありません。
GUI サポート
多くのプログラマーは、コマンドラインを用いて作業するよりも、バージョン管理システムを操作するグラフィカルインタフェースを使用して作業することを好みます。Mercurial での作業を簡単にする、いくつかのサードパーティー製の GUI が作られています。
そのツールの一つが SourceTree です。Atlassian が提供する、Git と Mercurial 用の無料 Mac クライアントです。SourceTree は簡単に使えるアプリケーションで、Bitbucket、Kiln、(Git ユーザーには) GitHub といった多くの人気のあるソースコードホスティングツールと接続できます。
TortoiseHg はまた別のツールです。成熟して、安定した GUI により Mercurial の作業を行える、Windows、Linux、OS X 用のシェルエクステンションです。 TortoiseSVN あるいは TortoiseCVS に慣れているプログラマーは、かしこまること無く TortoiseHg を使えるでしょう。
人気のある Eclipse IDE を開発において使用しているならば、MercurialEclipse と呼ばれるプラグインがあります。Mercurial を Eclipse に統合するので、IDE から離れることなく作業できます。
Windows サポート
Mercurial における Windows サポートは一級品です。 Mercurial は Windows ユーザーを大切にしており、完全なクロスプラットフォームであることにとても気を使っています。Windows マシン上で、ソースから Mercurial のコアを作成し、もし必要であれば、事前にパッケージ化されたバイナリーに依存することなく使用できます。
Git は、その一方で、コードのコアにおいて Windows サポートを提供していません。Windows 用の互換性を追加する msysgit と呼ばれるプロジェクトがあります。しかし、それは一般的に Linux 上での Git よりも遅くなることが報告されており、またそれが完全に独立したプロジェクトであるという事実は、Windows ユーザーに対しての Git の態度を表しています。
後方互換性
Mercurial のメンテナー (そして原作者) である Matt Mackall は後方互換性の強力な支持者です。それは、長期間に渡り信用できるバージョン管理システムを選択する際の重要な点です。
拡張が容易
Mercurial での作業に慣れたと感じるころには、あればいいなという機能がおそらくでてくるでしょう。Mercurial の開発者と話して、その機能を誰かに実装してもらうようにすることもできますが、たくさんの時間と努力が必要です。（そしてその機能を全く実装しないという決断になる可能性もあります。）
Mercurial は、誰もが異なるニーズを持っていることを知っており、コアコードを変更することなく機能を拡張できるいくつかの方法を提供しています。
Mercurial を拡張する一つ目の方法は、コマンドラインインターフェースを呼び出すシェルスクリプトを書くことです。ほとんどの Mercurial コマンドの出力は、”人間が読めるけれど簡単に解析できる” 形式に従っています。必要なことを実行するためのシェルスクリプトを書くのは非常に簡単です。例えば、http://dpaste.com に現在の差分を自動的に貼り付けるコマンドを追加したいとしましょう。それを行うために “hgpastediff” と呼ばれる小さなシェルスクリプトを書くことができます。
|
1
2 3 4 5 6 7 8 9 10 11 12 |
#!/usr/bin/env bash
hg diff | curl -si -F ‘content= Once that script is on your path you can simply run <code>hgdiffpaste</code> to paste the code to dpaste, and the location of the paste will be printed for you. As we mentioned in the last section, Mercurial is committed to maintaining a backwards-compatible command line interface, so you’ll almost never have to worry about your shell scripts breaking when you update to a new version. Another way to extend Mercurial is to use aliases. Aliases let you define new Mercurial commands that run other commands, possibly with arguments. For example, if you work with someone named Alice and merge with her often, you may find yourself typing <em>hg commit –message "Merge with Alice."</em> often. You can define an alias in your <em>~/.hgrc</em> file to cut down on this typing: [cc lang="xml"] |
Mercurial のバージョン 1.7 では、”シェルエイリアス” と呼ばれる機能があり、シェルコマンドを実行するエイリアスを定義できます。シェルエイリアスを用いれば、”dpaste に貼り付ける” 機能のために別のシェルスクリプトファイルを作成せずにすみます。
[cc lang=”xml”]
[alias]
diffpaste = !hg diff | curl -si -F 'content=
シェルエイリアスは、新しいコマンドを作成するための素早くて手近な方法であり、仕事を楽にします。
時に、シェルスクリプトは、Mercurial において機能を追加するほどに十分に強力ではありません。その時は、エクステンション API を用いて独自の Mercurial エクステンションを作成できます。エクステンションはとても一般的で美しいプログラミング言語 Python で書かれています。 (Mercurial 自身も同様。)
エクステンションを作成すると、Mercurial 内部の全てにアクセスできるようになり、それは、想像できる全てのことができるということを意味します。
商用サポート
バージョン管理システムにおいてツールと同様に重要なのは、何かがおかしくなったときにサポートを得られるかどうかということです。会社内で経験のあるユーザーがいない場合に、有料のプロフェッショナルトレーニングを受けられるということも重要です。
Mercurial のサポートとトレーニングを受けられる場所はいくつかあります。もっとも最新のリストは、Mercurial の Wiki 上にあるサポートページです。
プロフェッショナルな Mercurial コンサルティングについて情報を得られるもう一つの場所は、新しく作成された mercurial-consulting メーリングリストです。もし特定のニーズがあり質問する場合は、このメーリングリストが最適でしょう。
ホスティングツールとサービス
プログラマーは一人で働くことはほとんどありませんし、ウェブ上で簡単に閲覧できる、リポジトリの集中型コピーを持っていると、しばしば役に立ちます。これを実現する方法はいくつかあります。
hg serve コマンドは、他の人たちがブラウザーで閲覧したり、プルできるウェブサーバーをローカルコンピューター上で起動できます。他の人と変更を素早く共有することが、これ以上ないほど簡単になります。より安全で永続的なサーバーについては、いくつかの選択肢があります。
Mercurial は hg serve に似ている repository-serving スクリプトをバンドルしており、人々の間でただリンクを共有する必要があるだけという、小規模な会社のニーズを満たすかもしれません。WSGI をサポートするほとんどのサーバー上で実行可能で、Mercurial 自身にも含まれています。
Atlassian の Bitbucket は、Git と Mercurial のためのホスティングサービスです。リポジトリをホスティングし、標準的な Mercurial サーバーよりも多くの機能を提供します。5 ユーザーまで無料のプランがあり、無制限のプライベードリポジトリを利用可能です。それよりユーザーが多い場合は有料になっています。Bitbucket を使用すると、プロジェクトをホスティングするためや、それ用の新しいウェブサーバーを設定するために新しくハードドライブを購入しなければと心配する必要がありません。Bitbucket では “すぐに使える” インターフェースが提供されています。
また、Atlassian の FishEye というものがあり、これを使用すると、Git、Mercurial、Subversion、その他のサポート対象システム内のリポジトリを閲覧したり検索できます。一つのインストレーション内で全て設定できます。FishEye はまた Bitbucket のリポジトリに接続し、高度な閲覧と検索を行うことが可能です。コードレビューのプロセスをもう少し改善したい場合は、Crucible という製品を FishEye に追加することができます。
Bitbucket と FishEye は、JIRA や Bugzilla といった人気のある課題管理ツールに接続可能です。
Mercurial、それとも Git？
Mercurial を選択するいくつかの理由について説明しました。分散バージョン管理システムの使用を検討したくなったかもしれませんね。次のブログ記事では、Git を使用することの利点を見ていきます。
Mercurial を選択したかどうかコメントをください。その理由を聞きたいですし、他の多くの読者もまたそれを聞きたいことでしょう。もし Hg を使用しないことを選択した場合、その理由もまたお聞きしたいです。
*本ブログは Atlassian Blogs を翻訳したものです。本文中の日時などは投稿当時のものですのでご了承ください。
*原文 : 2012 年 2 月 23 日、投稿 “Mercurial vs Git: Why Mercurial?”