バージョン管理システムが分かる13のキーワード：オープンソースソフトウェアの育て方（2/3 ページ）

[Karl Fogel， ]

バージョン管理にかんする用語集

　本書では、まだバージョン管理システムを使ったことがない人に対してその基本的な使い方を解説することはできません。しかし、幾つかのキーワードを知っていなければ、これ以降の議論についていけなくなるでしょう。ここで説明するキーワードは、どのバージョン管理システムでも共通に使われるものです。これらの言葉は、これ以降でも特に説明せずに使用します。たとえこの世にバージョン管理システムがなかったとしても、変更の管理をどうするかという問題が消えてなくなることはありません。この問題について語る際には、ここで取り上げたキーワードを知っていると便利です。

• コミット

　プロジェクトに変更を加えること。もう少しかしこまって言うと、変更した内容をバージョン管理データベースに格納し、そのプロジェクトが次に公開するリリースに反映されるようにすること。“コミット”は、動詞としても名詞としても用いられます。名詞として使った場合の意味は、“変更”とほぼ同じです。例えば次のように使用します。“Mac OS X 上でサーバがクラッシュするバグを修正してコミットした。ジェイ、悪いけどこのコミットの内容をチェックしてくれないかな？　もしかしたらメモリを確保する方法を間違っているかもしれないし”

• ログメッセージ

　各コミットに添付されたコメントで、そのコミットの内容や目的を説明するもの。ログメッセージは、そのプロジェクトのドキュメントの中で最も重要なものです。これは、実際に変更したコードの内容を人間が読んで分かりやすい言葉（“機能追加”“バグ対応”、あるいはプロジェクトの進ちょく状況など）に変換する意味合いがあります。このセクションの後半では、ログメッセージを適切なメンバーに配信する方法を説明します。また、章6.コミュニケーションのしきたりの成文化項では各メンバーにいかにして有用なログメッセージを書いてもらうかを説明します。

• アップデート

　ほかのメンバーの変更（コミット）をローカル環境に取り込むこと。つまり、ローカル環境を“最新版”にすること。これは非常に頻繁に行われる操作です。ほとんどの開発者は、自分のコードを一日に何度もアップデートします。それにより、自分の開発環境をほかのメンバーとほぼ同じ状態に保つのです。また、もし何かバグを見つけたときに、おそらくまだそれは修正されていないものであろうことを予想できるようにします。例えば次のように使用します。“ねぇ、このコードって、一番最後のバイトを読んでいないように見えるんだけど……。バグじゃない？”“うん。でもそれは先週修正したよ。最新版にアップデートしたらバグはなくなるはずだ”

• リポジトリ

　変更内容を格納するデータベース。例えば中央管理方式のバージョン管理システムでは、マスタリポジトリが1つだけ存在し、すべての変更内容がここに格納されます。分散管理方式の場合は、各開発者が個別にリポジトリを所有します。ほかのリポジトリとの間のデータ交換が、任意のタイミングで発生します。バージョン管理システムは、各変更の内容を記録しています。リリース時期には、特定の時点の内容をリリース用として指定します。中央管理方式と分散管理方式のどちらがよいかについて語りだすと、終わりのない宗教戦争に巻き込まれてしまいます。プロジェクトのメーリングリストでは、できるだけこの問題には触れないようにしましょう。

• チェックアウト

　リポジトリからプロジェクトの内容を取得する処理。チェックアウトを行うと、いわゆる「作業コピー」（次の項を参照ください）と呼ばれるディレクトリツリーが作成されます。このツリーに変更を加えた結果をコミットし、元のリポジトリに反映させます。分散型のバージョン管理システムの中には、作業コピーそのものがリポジトリでもあるものもあります。その変更内容を、ほかのリポジトリとの間でやり取りしたりする構造になっています。

• 作業コピー

　開発者がローカル環境に保持するディレクトリツリーで、この中にはプロジェクトのソースコードやWebページ、そのほかのドキュメントが格納されます。作業コピーには、バージョン管理システムが使用するメタデータも含まれます。このメタデータの中には、取得元のリポジトリの場所や現在の“リビジョン"（次の項を参照ください）などの情報が格納されています。一般に、個々の開発者は自分の作業コピーを取得してそこで開発を行います。そして、変更した内容のテストを済ませた上でそれをコミットします。

• リビジョン、チェンジ、チェンジセット

　“リビジョン”とは、指定したファイルやディレクトリの特定の時点の状態のことです。例えば、あるプロジェクトのファイルFのリビジョンが6であった場合に、誰かがファイルFを変更してコミットすると、Fのリビジョンは7となります。システムによっては、一度に行われたある特定の変更群を称して“リビジョン”“チェンジ”あるいは“チェンジセット”とするものもあります。

　バージョン管理システムによっては、これらの用語を明確に定義しているものもあります。しかし、一般的な考え方はどれも同じです。一連の流れの中の特定の時点（バグ修正が行われた個所など）を指定する方法を用意しているわけです。例えば、次のように使用します。“ああ、それなら彼女がリビジョン10で修正したよ”あるいは“彼女はfoo.cのリビジョン10でそれを修正したよ”

　特定のリビジョンを指定せずに話を進めている場合は、一般に最新のリビジョンについて語っているものと考えていいでしょう。

• 差分

　変更内容を表すテキスト。変更があった個所とその前後数行について、変更前と変更後の状態を表示します。元のコードになじみがある人なら、差分を見ればどこをどう変更したのかが分かります。時にはバグを見つけたりすることもできるでしょう。

• タグ

　指定したリビジョンを構成するファイルにつけるラベル。タグは、プロジェクトの特筆すべき時点の状態を保護するために使用することが多くなります。特筆すべき点とは、例えば一般向けのリリースなどが挙げられます。リリースごとにタグをつけておけば、そのリリースとまったく同じ内容のファイル群をバージョン管理システムから簡単に取得できるようになります。タグの名前としてよく用いられるのは、Release_1_0やDelivery_00456といったものです。

• ブランチ

　プロジェクトの一部でありバージョン管理下に存在するが、ほかとは隔離されている部分。ブランチに対して適用した変更はそのほかの部分に対しては影響をおよぼしません。逆も同様です。ただし、明示的に“マージ”した場合は別です（以下を参照ください）。ブランチは、“開発ライン”と呼ばれることもあります。明示的にブランチを作成していない場合でも、“メインブランチ”で開発を進めているものと考えます。このブランチのことは“メインライン”あるいは“トランク（trunk）”と呼ばれることもあります。

　ブランチを使用すると、複数の開発ラインを別々に管理できます。例えば、本流の開発ラインとは別に実験的な開発用のブランチを作成し、本流を不安定にさせる可能性があるような開発はそちらで行えます。あるいは逆に、新しいリリース用の安定版ブランチを作成するといった使用法もあります。この方式の場合、リリースが間近に迫っても、通常の開発は本流ブランチ上で途切れなく続けられます。一方、リリース用ブランチではリリース作業に入った段階でコミットを停止し、リリース管理者が許可しない限りはコミットをしないようにします。この方式を採用すると、リリース前にいったん開発を中断する必要がなくなります。ブランチについての詳細は、本章の後半にあるブランチの活用項をご覧ください。

• マージ（あるいはポート）

　変更内容を、あるブランチから別のブランチに移動すること。本流の変更内容をほかのブランチに適用したり、その逆を行ったりすることも含みます。実際のところ、ほとんどのマージ作業はこのパターンです。本流以外の2つのブランチ間でのマージはほとんどありません。この手のマージについては情報の一元管理項をご覧ください。

　“マージ”にはもう1つの意味もあります。1つのファイルに対して複数人が別々の個所を変更したときに、バージョン管理システムが行う処理のことです。お互いの変更が相手の変更を邪魔することはないので、手元で修正済みのファイルをアップデートすると、相手の変更内容が自動的にマージされ（取り込まれ）ます。これは、複数の人が同じファイルをハックしている場合によくあることです。万一お互いが変更した個所が重なっていた場合は、次に説明する“コンフリクト”状態になります。

• コンフリクト

　1つのコードの同じ個所を異なる人が変更しようとした際に起こる現象。バージョン管理システムは、コンフリクトの発生を自動的に検出します。そして、変更しようとしたユーザーに対してそれを通知します。発生したコンフリクトを解決するのは、変更しようとした人たち自身の責任です。解決した後で、それをバージョン管理システムに通知します。

• ロック

　特定のファイルやディレクトリを、他人に変更されないように宣言する方法。例えば“Webページの変更内容をコミットしようとしたけどできない。たぶん、アルフレッドが背景画像を修正する間、すべてのファイルをロックしているんだろう”というように使います。中にはロック機能を持っていないバージョン管理システムもあります。また、その機能を持っていたとしても、実際にそれが必要となることはあまりないでしょう。いろんな人が同時に平行して開発を進めるのが普通の状況なのであり、ロックして他人を締め出すのはこの理想に相反するものです。

　コミットするにはロックが必要となるバージョン管理システムのことを、「ロック-修正-ロック解除（lock-modify-unlock）モデル」といいます。一方、ロックが必要でない方式のことは「コピー-修正-マージ（copy-modify-merge）モデル」といいます。2つの方式について深く掘り下げて比較した素晴らしい文書がこちら（日本語訳）にあります。一般に、オープンソース開発ではコピー-修正-マージモデルの方が適しています。本書で扱うバージョン管理システムは、すべてこの方式を採用しています。