バージョン管理システム Git を試してみた
April 9, 2018 – 11:30 amいまさらという感じもなくはないが、バージョン管理システムGitを試してみた。
「驚くほど凄い」というのが第一印象だ。
このGitシステムをローカルな計算機環境下に限定して使用するのはそう難しくはない。すぐにでも使用することができるし、かなり役に立つ。ただ、このシステムのもつ機能の全てに精通し使いこなすことができるのかというと話は別だ。かなり奥が深く、学べば学ぶほど活用する範囲が広がる興味深いシステムだ。
このエントリーでは、私がGitシステムを使用するうえで役に立ちそうな情報と感じたことを簡単にメモしておいた。
Git上でのデータの流れとその構造：
Fig.-1 Gitシステムにおけるデータの流れ
右図は、Git におけるデータの流れの概略を示している。
Repositoryにはバージョン管理の対象とする全データが過去に遡り保存されている。Repository上の最新の（もしくは任意の開発時点の）データ群は作業領域（Working-Tree)上に呼び出され、開発・編集作業の対象となる。開発・編集作業の節目ごとに作業領域上のデータはIndex化される。Index化されたデータはRepositoryに登録（Commit）される。
Fig.-2 Repository上のデータの構成
右図はRepository上のデータがどのようなかたちで保存されているかを示している。
緑の円のひとつひとつはCommitであり、各々はRepositoryに登録(Commit)された時点の全データの情報を保持している。円（Commit)の並びは、各々のCommitが親子関係になることを示し、図の下方に向かって過去に遡る。この系統図は Branchと呼ばれる。
図の右側にある紫の三角形、そしてピンクの四角形は夫々tree、blobと呼ばれる。雑な説明になってしまうが、UNIXのファイルシステムのDirectory情報がTreeに、個々のファイルの中身がblobに夫々対応すると考えてもよさそうだ。図に示されるように、UNIXのファイルシステムと同じように、treeは 階層構造を持っており、最下層にはファイルの内容を保持しているblobがある。
Git とUNIxのファイルシステムとの違いになるのだが、blobはファイルの内容をからなるが、これにはファイル名などデータの属性を表現するmeta-dataというものは含まれていない。これらmeta-dataは、これを保持するtreeに含まれる。
（注：上に掲げた二つの図は Git from the bottom up から引用掲載している）
Git is a content-addressable filesystem：
Gitの教科書の第10章2節（Git Internals – Git Objects) の冒頭に次のような記述がある：
Git is a content-addressable filesystem. Greate. What does that means? It means that at the core of Git is a simple key value data store. What this means is that you can insert any kind of content into a Git repository, for which Git will hand you back a unique key you can use later to retrieve taht content.
Git を少しだけ試した経験から、この記述がGitの特質を非常に良く表していると思った。この教科書には日本語訳もあるが、この文の意味するところをより明確にしようと敢えて「超訳」してみた：
Git システムは、ファイルのコンテンツに直接関連づけることができるファイルシステムである。この意味するとこところは、Gitシステムの肝(コア）がKey-Value型データストアにあるということだ。これにより、コンテンツのタイプがどのようなものであれ、Git-Repositoryに加えることができ、システムからはコンテンツに特有のキーを返してくる。以後、コンテンツのRepository からの取り出しはこのキーにより行なえる。
Key-Value型のデータ形式は、まさに、オブジェクトデータの形式だ。
ここで、コンテンツに直接関連づけできるキーとしてはhash（SHA-1)関数が用いられる。コンテンツそのものをhash関数の入力として出力するhash値をキーとして用いる。まさに、ファイルの中身（コンテンツ）自身が同じものには、全く同じキー、hash値が用いられる。
前節の Fig.2 にRepository上のデータの構成を示したが、３つのタイプのデータblob, tree, commitの夫々がそのコンテンツ（中身）に特有なキー(hash値）で検索することが可能になっている。また、Repository内のそれらデータは変化分のみが新しいデータとしてRepositoryに付け加わることになる。
この構成、今話題の仮想通貨の技術的基盤のブロックチェーンに類似している。
以上、Gitについて、私なりに理解を深めるために、こういうことだろうと思ったことを書いてみた。かなり抽象的な記述になってしまったので、次回以降、Gitシステムで具体例を示しながらバージョン管理の手続きについて書いてみたい。