Gitのリポジトリの中身をなるべく正確に理解する

自前の[ブログ](http://tbd.kaitoy.xyz/2015/12/27/git-repository/)からの転載。
(Qiitaにスライドってどう載せればよかったんだろうか。)

----------------------------
このエントリでは、[__Git__](https://git-scm.com/)の基本的な使い方は理解している前提で、そのリポジトリの構造をなるべく正確に説明する。
ここに書いてあることは概ね、筆者が[O'Reillyの蝙蝠本](https://www.oreilly.co.jp/books/9784873114408/)を読んで得た知識に基づく。

リポジトリの構造というとコアで上級者向けの知識のように聞こえるが、これをまず理解しておくことで強力で複雑なGitの機能を習得するのが非常に楽になる。
具体的には、Gitにおけるブランチの概念などの理解が深まったり、[`git reset`](http1/git-revert-reset/#git-reset)などのGit特有で分かり辛いコマンドを自信をもって使う上での最大のハードルである __インデックス__ や __HEAD__ の概念を完璧に理解できるというメリットがある。

チュートリアルを終えたくらいの初心者にこそ読んでほしいエントリである。

# Gitリポジトリの中身
Gitのリポジトリは、プロジェクトをクローンしたときとかにできる`.git`ディレクトリ内に詰まっている。
このディレクトリには、__オブジェクト格納領域__ と __インデックス__ というデータ構造が入っている。
また、__参照 (ref)__ や __シンボリック参照 (symref)__ というものも入っている。

以下、それぞれについて説明する。

### __オブジェクト格納領域__
オブジェクト格納領域は、ファイルシステム上では`.git/objects/`以下にあたる。

ここには、バージョン管理されているファイルの情報やそのコミット履歴などが保存されていて、具体的には以下の4種類のオブジェクトが置かれている。

1. __ブロブ__
    一つのファイルを表すオブジェクト。
    バージョン管理対象のファイルの内容(だけ)を保持する。

2. __ツリー__
    一つのディレクトリを表すオブジェクト。ブロブや別のツリーを指すポインタを持ち、またそれらが表すファイル/ディレクトリの名前や属性を保持する。
    つまり、これとブロブを組み合わせると、ファイルシステム上のディレクトリツリーを表すことができる。

3. __コミット__
    一つのコミットを表すオブジェクト。コミット日時やログメッセージなどの情報と、一つ前のコミット(親コミット)を指すポインタと、一つのツリーを指すポインタを持つ。
    このツリーはプロジェクトのルートディレクトリを表す。
    つまり、一つのコミットは、プロジェクトのある時点でのディレクトリツリー全体を表してもいる。

4. __タグ__
    一つの注釈付きタグ(`git tag -a`で作るタグ)を表すオブジェクト。
    タグ名やタグにつけたコメントなどの情報と、一つのオブジェクト(普通はコミット)へのポインタを持つ。
    因みに軽量タグ(`git tag`で作るタグ)はオブジェクトにならない。

ファイルシステム上で、一つのオブジェクトは一つのファイルに書き込まれ、[zlib](https://ja.wikipedia.org/wiki/Zlib)で圧縮され、`.git/objects/`以下に配置される。
そのファイルへのパスには、オブジェクトのコンテンツから計算されたSHA1ハッシュの値(i.e. オブジェクトの名前)が使われる。
例えば`.git/objects/16/cacde1ddabe1698b0e41e091e4697313e2b7e5`というファイルがあったら、これは __16cacde1ddabe1698b0e41e091e4697313e2b7e5__ という名のオブジェクトの実体。

`git cat-file -p <SHA1ハッシュ>`でオブジェクトのコンテンツを見れるので、いくつか見てみると面白い。
たとえばコミットオブジェクトは以下の様になっている。

```sh
$ git cat-file -p d444447526f91a97f2edeefc65d4f58e8e006d78
tree 5d43dfbb8dd89018b9a383d6b9f663166e3cf9f9
parent adcf8b197c6c156860dc8aa66ccb9a0c0a3bebb6
author kaitoy <kaitoy@pcap4j.org> 1480004891 -0700
committer kaitoy <kaitoy@pcap4j.org> 1480004891 -0700

[#76] Rmove unneeded makePacketForInvokingPacketField call from IcmpV4InvokingPacketPacket.
```

### __インデックス__
インデックスは、`git add`の説明とかに出てくる「インデックス」とか「ステージング」とか呼ばれる機能を実現するためのデータ構造で、ファイルシステム上では`.git/index`というバイナリファイルにあたる。

インデックスは、プロジェクトのある時点でのディレクトリツリー全体を表すデータをもつ。
具体的には、プロジェクトの各ファイルについて、対応するブロブへのポインタと、プロジェクトルートディレクトリからの相対パスが記録されている。

`git ls-files --stage`で`.git/index`の内容を見れる。
例として、`https://github.com/kaitoy/japanese-word-selection`をクローンして上記コマンドを実行すると以下の様に表示される。

```sh
$ git ls-files --stage
100644 ade14b9196fcad03cd0177c25ec1c31000ecf86a 0       .gitignore
100644 bbbbcd3415597bac39b0314f5c708d90684161fc 0       CHANGES.md
100644 f6b0b485fec1ee0bc53a452bc82cb6b7de2a1d91 0       LICENSE
100644 10e50f7b628d83f1b66f34f2d9d34029e7fc8670 0       README.md
100644 4dc8027d17765180fac5c3292a0195bb09b10ceb 0       assets/japanese-word-selection.gif
100644 dd92c48bae50307b55fb623c1b2beccab963096e 0       lib/japanese-word-selection.coffee
100644 8152af5ad39515fcd5021e3c8afee32910c0cf79 0       package.json
100644 9c0d180898d841bb319f51f1b1c7e07320426eeb 0       spec/japanese-word-selection-spec.coffee
100644 3d32fc0f42cc9babccd5525165e8227dce00a206 0       spec/japanese-word-selection-whitespace-spec.coffee
```

一行がひとつのファイルの情報で、左からファイルモード(パーミッション)、ブロブのSHA1ハッシュ、ステージ、ファイルパスが表示されている。
ステージは0～3の値になり得る。

ステージは普段は0だけだけど、マージコンフリクトが起きた場合は、ベースバージョン、一方のブランチのバージョン、他方のブランチのバージョンの3つをそれぞれステージ1、2、3としてインデックスに保持する。
これは、マージコンフリクトの解消(i.e. 3-wayマージ)を[サポートする機能](https://git-scm.com/docs/git-merge#_how_to_resolve_conflicts)のためだ。
### __オブジェクト格納領域とインデックスの図解__
ワーキングディレクトリに変更を入れ、`git add`、`git commit`をする中で、オブジェクト格納領域とインデックスがどう変化するかを図にした。

[SliedeShare - Git repo](http://www.slideshare.net/kaitoy-amada/git-repo)

* P. 1
![スライド1.PNG](https://qiita-image-store.s3.amazonaws.com/0/110166/b6111196-7736-9539-2e24-77e5008ec4b1.png)
* P. 2
![スライド2.PNG](https://qiita-image-store.s3.amazonaws.com/0/110166/63b24e5d-cf7f-5633-be10-bb4113fe005c.png)
* P. 3
![スライド3.PNG](https://qiita-image-store.s3.amazonaws.com/0/110166/4fde1c37-48b3-b252-ded8-1bdd0028d99d.png)
* P. 4
![スライド4.PNG](https://qiita-image-store.s3.amazonaws.com/0/110166/c7380ac7-14fa-9bd0-857d-dedad0077c15.png)
* P. 5
![スライド5.PNG](https://qiita-image-store.s3.amazonaws.com/0/110166/4e45d872-0bb0-c99d-2c82-2c38bf470cc7.png)
* P. 6
![スライド6.PNG](https://qiita-image-store.s3.amazonaws.com/0/110166/7266758a-5a22-6f85-8a7c-86284a2cc915.png)
* P. 7
![スライド7.PNG](https://qiita-image-store.s3.amazonaws.com/0/110166/f47a820f-6fb0-e4df-c072-e612b65c29c7.png)


(タグオブジェクトについては次の節で。)

スライドの1ページ目や最後のページのようにワーキングディレクトリとインデックスとオブジェクト格納領域が同期していて、`git status`を実行すると`nothing to commit, working directory clean`と表示される状態をワーキングディレクトリがクリーンであると言い、そうでない状態をワーキングディレクトリがダーティであると言う。

このスライドにより、Gitがファイルの履歴をどう記録しているかがよく分かるはず。
特に、ブロブが常にファイルのある時点の内容全体を保持していて、Gitが([Subversion](https://subversion.apache.org/)のように)差分を保存しているわけではないことは覚えておくべし。

スライドの最後のページのオブジェクト格納領域の図で、ツリーとブロブとそれらを指す矢印を省略すると、Gitのブランチ等の説明でよく見かける丸が矢印で連なった図(コミットグラフ)になる。以降の説明でそのような図を使うが、丸がコミットを意味していて、各コミットがルートツリーを指していることはよく認識しておくべし。

### __参照 (ref)__
参照は、一つのオブジェクトを指し示すポインタのようなもので、普通はコミットオブジェクトを指す。
参照には、__ローカルブランチ__、__リモート追跡ブランチ__、__タグ__ の三種類がある。

ファイルシステム上では`.git/refs/`以下にある、指し示すオブジェクトのSHA1ハッシュ値が書かれただけのテキストファイルにあたる。
`.git/refs/heads/`以下にローカルブランチ、`.git/refs/remotes/`以下にリモート追跡ブランチ、`.git/refs/tags/`以下にタグが置かれる。

参照は、Gitコマンドなどにおいてコミットを指定する方法としてSHA1ハッシュ値の代わりに使える。
この時、参照の名前は上記ファイルシステム上のパスから`.git/`を省いたものになる。
例えば`refs/heads/master`。さらに、ディレクトリは省略できるので、同じ参照は`heads/master`や単に`master`とも書ける。

ここで、ブランチやタグが単なる参照であるところに注目。
Subversionのようにリポジトリのコピーを作るのとはかなり異なる。
Gitのブランチを作るというのは単に参照を追加するだけだし、ブランチをチェックアウトするというのはブランチが指すコミットが指すツリーが表すディレクトリツリーをファイルシステムに展開するということ。
この実装によってGitのブランチが軽量で速いものになっている。

ローカルブランチの挙動を以下に図示する。図中で、各コミットには便宜上ラベルとしてアルファベットを付けている。

[SlideShare - Git branch](http://www.slideshare.net/kaitoy-amada/git-branch-56469696)

* P. 1
![スライド1.PNG](https://qiita-image-store.s3.amazonaws.com/0/110166/5a047597-fb23-d5f6-8698-48966b1d4298.png)
* P. 2
![スライド2.PNG](https://qiita-image-store.s3.amazonaws.com/0/110166/ab9dd9a9-8849-55dc-be25-1b91ef6c9fb7.png)
* P. 3
![スライド3.PNG](https://qiita-image-store.s3.amazonaws.com/0/110166/cfa52c78-b245-ee3d-52b8-e4110ef98027.png)
* P. 4
![スライド4.PNG](https://qiita-image-store.s3.amazonaws.com/0/110166/f08e0179-af3f-e735-fa34-69793c27a09c.png)
* P. 5
![スライド5.PNG](https://qiita-image-store.s3.amazonaws.com/0/110166/b84aff12-cadb-51ba-32c4-97edd73511d6.png)

このスライドの最後のページでmasterブランチが本流でbugfixブランチが支流かのように書いているが、実際は実装上それらに差はなく全く対等である。

また、ブランチは単なる一方的な参照であり、コミットオブジェクトからはそれに全く関与しないことに注意。
ブランチを削除してもそれによってコミットが消えることはない(※1)し、また例えば、スライドの最後のページでbugfixブランチを削除したらXがどのブランチで作られたコミットなのかを知るすべはなくなる。

(※1: ブランチを削除することにより到達不能になるコミットは、結果的に[`git gc`](https://git-scm.com/book/ja/v2/Git%E3%81%AE%E5%86%85%E5%81%B4-%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%86%E3%83%8A%E3%83%B3%E3%82%B9%E3%81%A8%E3%83%87%E3%83%BC%E3%82%BF%E3%83%AA%E3%82%AB%E3%83%90%E3%83%AA)により削除されはする。)

<br>

次に、タグの挙動を以下に図示する。

[SlideShare - Git tag](http://www.slideshare.net/kaitoy-amada/git-tag)

* P. 1
![スライド1.PNG](https://qiita-image-store.s3.amazonaws.com/0/110166/bcaf1583-1dd5-c6c3-044d-d5eab2d1360a.png)
* P. 2
![スライド2.PNG](https://qiita-image-store.s3.amazonaws.com/0/110166/d38293c8-db86-7457-706d-1b58d4208ed6.png)
* P. 3
![スライド3.PNG](https://qiita-image-store.s3.amazonaws.com/0/110166/3b876373-6b25-f870-0276-6a791d1b8ce2.png)
* P. 4
![スライド4.PNG](https://qiita-image-store.s3.amazonaws.com/0/110166/01347bb5-ecde-bc15-a7c1-c89b40133da1.png)
* P. 5
![スライド5.PNG](https://qiita-image-store.s3.amazonaws.com/0/110166/7351b295-0a04-f7a0-3eef-69524dc53bd3.png)

図中で、タグオブジェクトはオブジェクトなのでオブジェクト格納領域に入り、それを指す参照のタグは`.git/refs/`に入る。

<br>

リモート追跡ブランチについては[別のエントリ](http://tbd.kaitoy.xyz/2015/12/31/git-dvc/)で書く。

### __シンボリック参照 (symref)__
シンボリック参照は参照やオブジェクトを指し示すポインタのようなもので、以下の四つがある。

1. __HEAD__
    カレントブランチ、つまりチェックアウトしているブランチ(i.e. 参照)を指す。

2. __ORIG_HEAD__
    `git merge`や[`git reset`](http://tbd.kaitoy.xyz/2016/01/01/git-revert-reset/#git-reset)でHEADが更新されたとき、更新前のHEADが指していたブランチが指していたコミットを指す。

3. __FETCH_HEAD__
    最後にフェッチされたブランチの最新コミットを指す。

4. __MERGE_HEAD__
    マージ操作中に作られ、HEADにマージされようとしているコミットを指す。

それぞれが、Gitコマンドなどにおいてコミットを指定する方法としてSHA1ハッシュ値の代わりに使える。

ファイルシステム上では`.git/{HEAD,ORIG_HEAD,FETCH_HEAD,MERGE_HEAD}`にあたり、全て単純なテキストファイルである。

[SlideShare - Git HEAD](http://www.slideshare.net/kaitoy-amada/git-head)

* P. 1
![スライド1.PNG](https://qiita-image-store.s3.amazonaws.com/0/110166/af3f93af-cda4-1962-82b4-94bd4949cf54.png)
* P. 2
![スライド2.PNG](https://qiita-image-store.s3.amazonaws.com/0/110166/adb3a427-8638-56f7-7e47-d714cc0e8e96.png)

<br>

以上がGitリポジトリの中身のほぼ全容。あとは設定ファイルとかフックスクリプトとかがあるだけ。

<br>

実際のGitリポジトリのオブジェクト、参照、シンボリック参照を、この記事のスライドと同じ見た目でビジュアライズするツール、[__Goslings__](http://qiita.com/kaitoy/items/91585ba1a3081ffd2111)を作った。
このツールを使って実際のリポジトリの中身を見ながらこの記事の内容を確認すると、より理解が深まるかもしれない。