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

[Karl Fogel， ]

ブランチの活用

　バージョン管理システムにあまり慣れていないユーザーは、ブランチの作成やマージ作業を怖がる傾向があるようです。おそらく、これはCVSの悪評の副作用でしょう。CVSのブランチ作成処理やマージ処理は直感的とはいえず、多くの人がそれを避けるようにしています。

　もしあなたもその中の1人なら、怖がる気持ちを乗り越えてブランチ作成やマージについて勉強してみましょう。いったん作業に慣れてしまえば、そんなに難しいものではありません。また、プロジェクトに参加するメンバーが増えれば増えるほどこの作業の重要性も増します。

　ブランチを使用すると、限られた資源（プロジェクトのソースコード中の作業場所）を有効活用できるので便利です。通常は、すべての開発者が1つの砂場の上で作業をします。みんなで1つのお城を作っていこうとしているわけです。あるとき、1人のメンバーが「ここに跳ね橋をつけましょうよ」といい出しました。でも、ほかのメンバーは、それがそのお城にとって本当に有用なのかどうかが分かりません。そのメンバー用に砂場の一角を隔離し、彼女にはそこで作業をしてもらう。ブランチを作成するとは、そういうことになります。もしうまい具合に跳ね橋ができ上がったら、彼女はほかのメンバーを呼び寄せてそれを見てもらいます。みんなが納得するようなできであることが分かれば、バージョン管理システムを使ってその跳ね橋をみんなのお城に移植（マージ）するのです。

　共同作業を進める上でこの機能がいかに有用かは、言うまでもないことでしょう。この機能を使えば、「ほかの人に迷惑が掛からないかな？」なんて気にせずに思う存分新しいことを試せるのです。同じくらい重要なこととして、バグ修正や安定版リリースのためのブランチを本流から隔離する（章7.パッケージの作成、リリース、日々の開発のリリースを安定させるプロセス項と複数のリリースラインを管理する項を参照ください）ことがあります。そうすれば、それぞれの流れを追いやすくなります。

　偏見を捨て、ブランチを積極的に使うようにしましょう。そして、ほかのメンバーにもブランチの使用を推奨しましょう。しかし、不要になったブランチはいつまでも残しておかないようにしましょう。ブランチが増えれば増えるほど、コミュニティー内での注目が散らばります。そのブランチとは直接関係のない開発者でも、周りで起こっていることを気にせずにはいられないでしょう。無理もありません。もちろん、ブランチに対するコミットであってもコミットメールは同じように送ります。しかし、ブランチは開発者のコミュニティーを分断する仕組みとなるべきではありません。わずかな例外を除いては、初期の目的を達成して本流にマージした時点でブランチを削除しましょう。

• 情報の一元管理

　ブランチが重要だということは、当然マージ処理も重要だということです。同じコミットを2回繰り返すなんていうことがないようにしましょう。つまり、ある変更がバージョン管理システムに投入されるのは1回だけにしておくことです。そうしておくことで、ある変更に対応するリビジョン（あるいはリビジョン群）が一意に決まります。その変更と同じ内容を別のブランチにも適用したい場合は、そのブランチ上でもまったく同じように手を加えてそれをコミットするのではなく、最初の変更をマージしましょう。手作業で同じように修正したものをコミットしても結果は同じですが、そうすると正確なリリース管理ができなくなります。

　この件にかんする実際のアドバイスは、使用するバージョン管理システムによって異なります。あるシステムでは、「マージ」は特別な処理として扱われ、通常のコミットとは別のものとなります。そして独自のメタデータを保持します。また、システムによっては、マージした結果を通常のコミットと同様に適用するものもあります。このようなシステムでは、「マージした結果のコミット」と「新しい変更のコミット」の区別はログメッセージで行います。マージした際のログメッセージには、元の変更の際のログをそのまま繰り返してはいけません。そうではなく、「この変更はマージである」ことと、どのリビジョンをマージしたのかを簡単に記述するようにします。実際の変更内容を知りたければ、マージ元のログメッセージを見るようにするわけです。

　ログメッセージの重複を避けるのがなぜそんなに大事なのかというと、ログメッセージは後から修正される可能性があるからです。同じ内容のログを繰り返し記述していると、だれかが元のログメッセージを修正したときにコピー先のメッセージがそのままになってしまう可能性があります。後から見たら、これは非常にややこしい状況になります。

　同じ原則は、変更を取り消す（revert）際にも当てはまります。ある修正が廃案になったときのログメッセージは、単にそれがrevertされたことだけを記述します。実際に何をどのように戻したのかまでを書いてはいけません。だってそれは、もともとその変更を行った際のログを見れば分かることなんですから。もちろん「なぜ」取り消したのかという理由の説明は必要でしょう。しかし、元の変更の際のログメッセージを一言一句書き写す必要はありません。できれば、元の変更の際のログメッセージも修正し、それが結局取り消されたことを記述しておくとよいでしょう。

　これまで説明してきたことからも何となくお分かりでしょうが、特定のリビジョンを参照する際の表記方法は統一しておいた方がいいでしょう。これは、ログメッセージだけでなくメールやバグ追跡システムなどでも同じです。CVSを使っているのなら、“path/to/file/in/project/tree:REV”という形式をお勧めします。ここで、REVはCVSのリビジョン番号（例えば“1.76”など）を指します。Subversionを使っているのなら、（例えばリビジョン1729の場合の）標準の表記法は“r1729”となります（ファイルのパスは不要です。Subversionはリポジトリ全体でリビジョン番号を管理するからです）。それ以外のシステムでもきっと、チェンジセットを表すための標準形式があることでしょう。ともかく、メンバーには標準の形式を使ってもらうようにしましょう。この表記法を統一しておくと、後からプロジェクトの流れを追うのが簡単になり（章6.コミュニケーションや章7.パッケージの作成、リリース、日々の開発で説明します）ます。これらの管理を行うのはたいていはボランティアなので、できるだけ簡単に進められるようにしておくことが重要です。

　章 7. パッケージの作成、リリース、日々の開発のリリースと日々の開発項もご覧ください。