1.1 使い始める - バージョン管理について

多くの人が選ぶバージョン管理方法は、ファイルを別のディレクトリ（もし賢ければタイムスタンプ付きのディレクトリ）にコピーすることです。この方法は非常にシンプルであるため一般的ですが、信じられないほどエラーが発生しやすいです。自分がどのディレクトリにいるのかを忘れ、誤って間違ったファイルに書き込んだり、意図しないファイルを上書きしたりすることが簡単に起こります。

この問題に対処するため、プログラマたちはずっと以前から、リビジョン管理下のファイルに対するすべての変更を保持するシンプルなデータベースを持つローカルVCSを開発しました。

最も人気のあるVCSツールの一つは、今日でも多くのコンピューターに配布されているRCSと呼ばれるシステムでした。RCSは、パッチセット（つまり、ファイル間の差分）をディスク上の特殊な形式で保持することで機能します。その後、すべてのパッチを合計することで、任意の時点での任意のファイルの見た目を再作成できます。

人々が次に遭遇する大きな問題は、他のシステム上の開発者と共同作業する必要があることです。この問題に対処するため、集中型バージョン管理システム（CVCS）が開発されました。これらのシステム（CVS、Subversion、Perforceなど）は、すべてのバージョン管理されたファイルを格納する単一のサーバーを持ち、その中央の場所からファイルをチェックアウトする多数のクライアントを持ちます。長年にわたり、これがバージョン管理の標準でした。

この設定は、特にローカルVCSと比較して多くの利点があります。例えば、プロジェクト内の誰もが他のメンバーが何をしているかをある程度把握できます。管理者は誰が何を行うかについて細かく制御でき、すべてのクライアントでローカルデータベースを扱うよりもCVCSを管理する方がはるかに簡単です。

しかし、この設定にはいくつかの重大な欠点もあります。最も明白なのは、集中サーバーが単一障害点となることです。そのサーバーが1時間ダウンした場合、その間は誰も共同作業ができず、作業中のものに対するバージョン管理された変更を保存することもできません。中央データベースのあるハードディスクが破損し、適切なバックアップが取られていなかった場合、プロジェクトの全履歴、つまりローカルマシンに偶然残っている単一のスナップショットを除いて、すべてを完全に失うことになります。ローカルVCSもこの同じ問題を抱えています。プロジェクトの全履歴が単一の場所にある限り、すべてを失うリスクがあります。

ここに分散型バージョン管理システム（DVCS）が登場します。DVCS（Git、Mercurial、Darcsなど）では、クライアントはファイルの最新のスナップショットをチェックアウトするだけでなく、リポジトリをその全履歴を含めて完全にミラーリングします。したがって、もし何らかのサーバーが停止し、これらのシステムがそのサーバーを介して共同作業していたとしても、いずれかのクライアントリポジトリをサーバーにコピーし直して復元することができます。すべてのクローンは、実際にはすべてのデータの完全なバックアップなのです。

さらに、これらのシステムの多くは、複数のリモートリポジトリと連携するのをうまく扱えるため、同じプロジェクト内で異なる人々のグループと異なる方法で同時に共同作業を行うことができます。これにより、集中型システムでは不可能であった階層型モデルなど、いくつかの種類のワークフローを設定することができます。