1.1 入門 - バージョン管理について

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

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

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

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

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

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

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

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