VCS History

Gitを覚える際はまずGitのコマンドではなく、バージョン管理システムの歴史を知ることが一番の近道のように思う。(これはGitに限らず、プログラミング言語などを教えるときも同様だ。)なぜそのシステムが必要なのか理解し、それを実現するためにこれまでVCSの開発に携わってきたエンジニアがどのような道のりを歩んできたかを知ることによって、深い理解を得られるはずだ。

導入

はじめに、そもそもバージョン管理システムはどういうものなのかを知る必要がある。

一言で言うと、 コンピュータで作成するファイルの作成・削除と編集の履歴を管理するためのシステム だ。ファイルの作成日付、変更日、変更点などをシステムで保管しておいて、いつでも過去のある地点の状態や変更内容を見たり、現在のソースコードをまるっきり過去の状態に戻したりできる。そのため、バージョン管理と呼ばれている。このページではファイルの変更点が管理できるというイメージと雰囲気さえ掴んでもらえれば良い。

Don't Think. Feel

もしバージョン管理システムが無ければどうなるか。これは例えばDropboxやGoogle Driveにそのままソースコードをアップロードして共有するようなもので、この場合だとフォルダやファイル名に日付や符号を追加していつアップロードしたものか判定することになる。

  • ソースコード
  • ソースコード_旧
  • ソースコード_最新
  • ソースコード_新

たしかにバージョン管理ができてはいるのだが、手動で毎回最新版を保存するのはとても面倒くさいし管理し辛い。現在と過去の差分も分からない。ソースコードを扱うのが自分ひとりであるならまだ問題は起きないが、複数人がある時点のソースコードを編集した際、統合するのは手動になる。これは苦行であり、発生しないはずのバグも発生させてしまう。

ここで、バージョン管理システムを使う。バージョン管理システムを利用することで手動だった名前分けは自動になり、複数人で編集した際の苦行のような統合作業は必要なくなり、簡単に過去のある地点までプロジェクトを巻き戻すことが可能で、手動では不可能だったブランチなどといった複雑な操作も不具合無く実行できるようになる。一般的なバージョン管理システムの開発フローを取り入れることで開発速度は上がり、バグも減り、彼女も出来る。

歴史

ある程度バージョン管理システムの役割を掴めたならば、バージョン管理システムの歴史を順に辿る。もちろんバージョン管理システムが存在しなかった頃は前述したような管理方法が一般的だったのだろうが、そこからどのようなシステムが生まれ、現在最も一般的な Git が生まれたのかを簡単に説明する。

Gitも何もないところから突然生まれたわけではなく、小さく始まったシステムに沢山のアイデアが引っ付いて今の形になったのだ。VCSの変化は大きく分けて4つに分割される。

  • 1982年: RCS(ロックアンドモディファイ)
  • 1990年: CVS(エディットアンドマージ)
  • 2000年: svn(アトミック・コミット)
  • 2005年: git(分散バージョン管理)

1982年: RCS(ロックアンドモディファイ)

Revision Control System は初期のバージョン管理システムのひとつで、当時でもプログラムのソースコードや文書などの頻繁に改版されるテキストの管理に利用されていた。

RCSで利用されているロックアンドモディファイの方式では、編集するファイルにロックをかけて他のユーザが編集できないようにしておき、自分の編集が完了したらコミット(ファイルへの書き込み)を行ってロックを解除する方式が取られている。

この時点では複数人での編集は想定していなかったのでファイルにロックをかけて1人ずつ、RCSはプロジェクトの管理も想定していなかったのでファイル単位でしか管理することができなかった。

複数人での管理は想定していなかったので仕方ないが、コミット(ファイルへの書き込み)されなければ、他の人が永遠にそのファイルを編集することができないという難点がある。

この時点でのコミットとは、編集を確定し、変更を実ファイルに反映させることだ。

1990年: CVS(エディットアンドマージ)

Concurrent Versions System はRCSの派生として生まれたバージョン管理システムだ。ファイルの変更は差分を取り込むという形で実現し、RCSで想定されていなかった複数人での編集を可能にした。サーバー上のファイルをローカルに落として編集し、差分だけアップロードするネットワーク機能や、他にもGitのような枝分かれバージョン管理の機能(ブランチ)もこの頃には実装されていた。

CVSで利用されているエディットアンドマージ(コピー・マージ方式)では編集するファイルをシステムからローカルにコピーし、このコピーを編集する。編集が完了したら差分をシステム上のファイルと合体させる。元ファイルとの差分のみを取り込むマージ機能によって、CVSでは複数人が同じファイルを編集することが可能になった。(コンフリクトが発生した時は、コミット時にマージ作業が発生する)

2000年: SVN(アトミック・コミット)

Subversion はCVSの派生として、CVSの不具合や設計上の難点を解決するために生まれたバージョン管理システムだ。SVNはCVSの難点を解決する他にもアトミック・コミット機能を実装、同時にバージョン管理システム管理下のディレクトリの移動や削除をサポートしたため、プロジェクト単位でのバージョン管理が格段にやりやすくなった。

ただし、SVNもまだ集中型バージョン管理システムであり、サーバー上のファイルをローカルに落として編集し、コミットするやり方だった。SVNで実装されたアトミック・コミットでは、今までは1コミット1ファイルであったものを、1コミット複数ファイルを可能にした。(1コミットで複数のファイルをサーバーのリポジトリ(管理されたプロジェクト)に反映できる)

2005年: Git(分散バージョン管理)

Git はLinuxカーネルの開発のために、当時使用していた分散バージョン管理システム BitKeeper の代用として開発された分散バージョン管理システム。Linuxカーネルを管理するため、バージョン管理のための多数のアイデア、機能が実装された。

開発の一般的な流れとしてサーバーからローカルにリポジトリをダウンロード(clone)するところは他と変わらないが、分散バージョン管理システムでは、インターネットに接続されていなくてもコミットを行えるという点が今までのバージョン管理システムとは違っている。ここで言うコミットは、 ファイルの変更をアップロードし、サーバーのファイルを書き換える ではなく ローカルのファイルの変更を確定する という意味だ。手元のコミットをサーバーのリポジトリに適用するには、アップロード(push)を行う。

分散バージョン管理システムの登場により、サーバーに繋がっていなくてもローカルでコミットが出来るようになった。Gitの多彩な機能のおかげもあり、バージョン管理はローカルでコミット、リポジトリへプッシュするスタイルが確立されていった。

(現在でもSubversionを使い続けている現場は多いため、安易にディスると刺される)

results matching ""

    No results matching ""