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

[Karl Fogel， ]

• 承認

　たいていのバージョン管理システムには、特定のユーザーに対してリポジトリ内の特定の場所だけのコミットを許可したり逆に拒否したりする機能があります。「ハンマーを与えられたら、人はみんな周囲の釘を探すようになる」という原則どおり、多くのプロジェクトでこの機能が使われてきました。アクセス権を注意深く管理し、特定の場所にだけコミット権を与えてほかの場所は触らせないようにするといった具合です（章8.ボランティアの管理のコミッター項で、コミット権の管理方法について説明しています）。

　このように厳格に管理してしまえば、悪影響が出る可能性を減らせることでしょう。しかし、もうすこし緩やかな方針でも構いません。プロジェクトによっては、緩やかな方針を採用しているものもあります。たとえリポジトリの一部分のみへのコミット権を与えられたユーザーでも、設定上はリポジトリ全体を変更できる権限を与えるというものです。ただ「コミットするのはこの範囲だけにしておいてね」とお願いするだけです。こうしたところで、実害はないことを覚えておきましょう。普通のプロジェクトなら、すべてのコミットは何らかの形でレビューされます。誰かが予期せぬコミットをしたら、それを見つけた人が何かコメントすることでしょう。その変更を取り消すべきだと判断したのなら、やることは簡単です。すべてバージョン管理されているのだから、単にその変更を取り消せばいいだけのことです。

　緩やかな方針にしておく利点は幾つかあります。まず、ある開発者の権限を拡張する（プロジェクトに長年かかわっていると、よくあることです）場合に一切手間が掛からないことです。単に「今日からは、ここもコミットしていいよ」というだけで、後はすぐにコミットできるようになります。

　次に、より緻密な方法で権限の拡張ができるようになります。一般に、エリアXのコミッターがエリアYにもコミットしたいと考えた場合は、まずYに対するパッチを投稿してレビューしてもらうことになります。すでにYへのコミット権を持つメンバーがそのパッチをレビューして承認したら、パッチを投稿した人に対して「直接コミットしてもいいよ」と伝えます（もちろん、誰がレビューして承認したのかという情報はログメッセージに残しておきます）。この方法だと、実際にパッチを書いた人がコミットをすることになります。これは、情報管理の面でも功績をたたえる意味でも重要です。

　最後に、最も重要なのが、この緩やかな方式を採用するとお互いに信頼し、尊重しあう空気が生まれることです。この方式の場合、「君はこの部分にコミットする能力があることが分かった。ぜひコミットしてくれ」というように取られます。厳格に管理してしまうと「君のできることには制限があるんだ」ということを強調するだけでなく「間違って変なことをしてしまわないかどうかが心配なんだ」と疑っているように感じられてしまいます。できればこのようなことは避けたいでしょう。だれかを新たにコミッターとして迎え入れることは、みんなの信頼の輪の中に新しいメンバーを加えるということです。その際には、本来必要なもの以上の力を与え、「それをどう使うかはあなた次第。でもこれ以上のことはしないでね」とした方がいいでしょう。

　Subversionプロジェクトでは、かれこれ4年以上この「緩やかな管理」方式を採用しています。本書の執筆時点で、フルコミッターは33人、一部にだけコミット権限のあるメンバーが43人います。この管理方式では、システムが管理するのは「コミッターかそうでないか」だけです。その詳細（どの部分にコミット権があるかなど）は人間が管理します。今のところ、コミット権のない部分について故意にコミットするなどといった問題は発生していません。コミット権にかんする誤解が生じたことも何度かありましたが、いつも速やかに円満解決していました。

　このような自己管理方式が明らかに現実的でない場面もあるでしょう。当然、そんな場合は厳格な管理が必要となります。とはいえ、そんな状況はまれです。たとえ何千人の開発者が何百万行のコードを扱っていたとしても、そのコードに対するすべてのコミットはだれかほかの人によるレビューを受けます。おかしなコミットがあればすぐに指摘されるでしょう。もしコミットをレビューしあう習慣ができていないのなら、それは認証システムがどうのこうのいう以前の問題です。

　まとめると、よほどの理由がない限りはバージョン管理システム上のアクセス権限にあまり気を使う必要はありません。厳密に管理したところで得られる具体的なメリットはあまりありません。それより人間による管理に頼った方が得られるものは多いでしょう。

　もちろん、制限をすること自体が無意味だといっているわけではありません。権限のないところへコミットさせるようなことは、あまりしたくないでしょう。さらに、多くのプロジェクトでは「フルコミッター（制限のないコミッター）」には何らかの特権（例えばプロジェクトの運営にかんする投票に参加できるなど）が与えられています。コミット権の扱いにかんする政治的な意味合いについては章4.プロジェクトの政治構造と社会構造の誰が投票するのか？項で詳しく説明します。

著者：Fogel Karl

翻訳者：高木 正弘

翻訳者：Takaoka Yoshinari(a.k.a mumumu)

製作著作 © 2005, 2006, 2007, 2008, 2009 Karl Fogel, 高木正弘, Yoshinari Takaoka(a.k.a mumumu), under a CreativeCommons Attribution-ShareAlike (表示・継承) license (3.0, 2.1-jp)

よいフリーソフトウェアを作ることは本質的に価値のある目標です。その方法を模索している読者の皆さんが、本連載「オープンソースソフトウェアの育て方」で何かのヒントを得てくだされば幸いです。

原文へのリンク