バージョン管理システムのすすめ：オープンソースソフトウェアの育て方（2/4 ページ）

[Karl Fogel， ]

• コミットメール

　コミットが行われるたびに、その内容をメールで送信するようにします。メールには「だれが」「いつ」「どのファイルやディレクトリを」「どのように」変更したのかを記述します。このメールの送信先は独立したメーリングリストとし、人間が投稿する普通のメーリングリストとは独立させましょう。コミットメールを受け取りたいひとだけがそのメーリングリストに参加することになります。開発者やプロジェクトに興味があるそのほかの人たちには、このメーリングリストへの加入を勧めましょう。今そのプロジェクトに何が起こっているのかをコードレベルで知るために、このメーリングリストは最適な手段となります。ピアレビューの技術的な有用性についてはあらためて語るまでもありません（きちんとしたコードレビューの習慣項をご覧ください）が、コミットメールもコミュニティーにおいては有用なものとなります。すべてのイベント（コミット）の内容が共有されることで、ほかのメンバーがそれに反応したりといったことがしやすくなるのです。

　コミットメールの設定方法は、使用するバージョン管理システムによって異なります。しかし、通常はそれ用のスクリプトやパッケージが用意されているはずです。もし見つからなければ、使用しているシステムのドキュメントでフック（hooks）、あるいはコミット後フック（post-commit hook）といったキーワードで探してみましょう。ちなみにCVSではloginfoフック（loginfo hook）というようです。コミットがあるたびに自動で特定の作業をさせる際に使用するのがコミット後フックです。これは各コミットの直後に呼び出され、そのコミットにかんする情報を受け取って任意の作業を行うことができます。そう。例えばメールを送信したりなど。

　用意されているメール送信の仕組みを使用していると、そのデフォルトの動作をちょっと変更したくなるかもしれません。

1. コミットメールシステムの中には、実際の差分そのものは本文に含めず、それをWebで見るためのURLだけを記載するものがあります。もちろんURLは大事です。後から変更内容を確認するのにも便利ですしね。でも、差分の内容そのものをメールの本文に含めておくことも非常に重要です。

　多くの人にとって、メールを読むという作業は日常のルーチンワークとして組み込まれているでしょう。変更の内容が直接メールに書かれていれば、一連の流れの中で自然にコミットをレビューできます。いちいちメールソフトを終了してブラウザに切り替える必要がなくなるのです。変更を確認するにはURLをクリックする必要があるとなれば、ほとんどの人はクリックなどしないでしょう。だって、これまでずっとメールを読んでいたのに、いきなり別の操作が必要となるのですから。さらに、変更点をレビューした人がその内容について質問をしたいときに、そのメールに「返信」すれば自動的に変更内容が得られるので便利です。さもないと、Webページを開いて変更点をカット＆ペーストするという大変な手間が掛かってしまいます。

　（もちろん、新たにリポジトリにコードを追加したなどで変更点が大量にある場合は、差分を省略してURLだけにするのも分かります。コミットメールのシステムの多くは、何らかの制限値を設定してこの処理を自動化してくれます。もしそんな機能がついていなかったとしましょう。そんな場合でも、差分をまったく記載しないよりは常に差分を含めるようにする方がずっとマシです。たまに巨大なメールが送信されますが、許容範囲です。共同開発においては、みんなが他人の変更をレビューしたりコメントしたりすることが重要です。そのための努力は、幾らしてもし過ぎることはありません）

2. コミットメールのReply-toヘッダは、コミットメール用のメーリングリストではなく開発者向けのメーリングリストにしましょう。そうすると、コミットメールの内容をレビューして何らかのコメントをしたくなった人が「返信」すると、それが自動的に開発者向けメーリングリストに流れます。

　こうしておくべき理由は幾つかあります。まず、技術的な議論は1つの場所に集約すること。技術的な議論を行う場として最適なのは、開発者向けメーリングリストです。次に、コミットメール用のメーリングリストに参加していないメンバーにも議論の内容を伝えること。3つ目に、コミットメール用のメーリングリストはあくまでもコミットの内容をチェックするだけのものであり、決して「コミットの内容のチェックがメインだけど、たまに技術的な議論もある」ものであってはいけないからです。

　コミットメール用のメーリングリストに登録する人たちは、コミット内容のメールだけが送られてくることを期待しています。それ以外の内容が送られると、暗黙の了解を裏切ることになります。最後に、コミットメールの内容を処理して（Webページなどに）結果を出力するプログラムを作成するような人のことを考えること。この種のプログラムは、コミットメールのようなお決まりのパターンのメールにかんしてはうまく動作します。しかし、人間が書いたメールを処理させると変な結果になってしまうでしょう。

　ここでお勧めしたReply-toの設定は、決してReply-toはどうすべきか項の内容と矛盾するものではないことに注意しましょう。先ほども、メッセージの送信者自身がReply-toを設定する分には特に問題はないとしています。今回の場合、メッセージの送信者はバージョン管理システムです。バージョン管理システム自身でReply-toを指定して開発者向けメーリングリスト向けに返信させようとしているのですから、先ほどの説明とは矛盾しません。

CIA：変更点を公開するためのもう1つの方法

　変更点を公開する方法は、コミットメールだけではありません。最近、CIAと呼ばれる別の仕組みが開発されました。CIAは、コミットの状況をリアルタイムで収集し、配信するものです。CIAの最も一般的な使用法は、コミットの通知をIRCチャンネルに送信するものです。そのチャンネルに参加していれば、コミットがあるたびに即時にそれを知ることができます。メールに比べると、技術的に劣っているかもしれません。だって、IRCにコミット通知を送ったとしてもそれを見ている人がいるかどうかが分からないわけですから。それでも、この仕組みは社会的な面で面白いものです。参加している人たちはそこで何かが起こっていることが感じられ、開発の進行状況をまさに目の前で見られるわけです。

　この仕組みを使用するには、コミット後のフックでCIAの通知用プログラム（CIA notifier）を実行します。このプログラムは、コミットにかんする情報をXML形式に変換して中央サーバ（通常はcia.navi.cx）に送ります。するとサーバがその情報を別のフォーラムに配信するのです。

　CIAを設定することで、RSSフィードを送信させることもできます。詳細はこちらのドキュメントをご確認ください。

　CIAが実際に動作している例を見るには、IRCクライアントでirc.freenode.netのチャンネル#commitsに行ってみましょう。