GoでGitを自作してみた＜前編＞

# はじめに
Gitの仕組みを理解しようと、Go言語でGitもどきを自作してみました。

その名も **「Goit」** です。

https://github.com/JunNishimura/Goit

今回自作しようと思った理由としては、
- Gitの仕組みを理解したかった
- Goで何かツールを作りたかった

などが挙げられます。

Goitの実装内容について記事を書こうと思っていたのですが、Gitの仕組みを解説するだけで記事のボリュームが大きくなってしまったので、この記事ではGitの概要、仕組みについてのみを書こうと思います。

Goitの実装内容については後日記事にして公開したいと思います。


### この記事で取り扱う内容
- Gitとは何か
- Gitの仕組み（Gitオブジェクト、リファレンス、インデックス

### この記事で取り扱わない内容
- Gitコマンドの紹介
- Gitコマンドの使い方

### この記事の対象者
- Gitを何となくで使っているけど、内部がどのようになっているのか分かっていない人
- Gitのようなバージョン管理ツールを自分でも作ってみたい人

# Gitとは何か？
## 概要
Gitはリーナス・トーバルズ（Linux開発者）によって開発された分散型バージョン管理システムです。

### バージョン管理システム
バージョン管理システムとは、ソースコードなどのファイルの変更履歴を記録、追跡することができるシステムのことです。

「バージョン管理」という言葉だけを聞くと、堅苦しく感じますが、誰しもが経験したことのある話です。学生時代にレポートや論文を書く時に、「課題_山田花子_ver1.docx」、「課題_山田花子_ver2.docx」という風に、バージョン毎にファイルを切り分けたことのある人は多いのではないでしょうか。そのバージョン管理を上手くやってくれるのがバージョン管理システムです。

編集対象にあるファイルの数が1つや2つで、ファイルの編集・閲覧に関わる人が自分だけの場合は、バージョン管理システムの必要性は感じないかもしれません。

バージョン管理システムの恩恵を受けるのは、ファイルの数が膨大で、かつ複数人にわたってファイルを編集、閲覧するような場合です。複数人でファイル編集を行う場合、「誰が」「いつ」「どこに」「どのような」変更をしたのかが記録され、共有されていなければ、色々なトラブルが発生することが予想されます。

### 分散型
Gitは分散型バージョン管理システムでDVCS（Distributed Version Control System）と呼ばれます。一方でSubversionのような集中型バージョン管理システムはCVCS（Centrlized Version Control System）と呼ばれます。

CVCSでは、一つのリポジトリのみが存在し、1つのサーバーでそのリポジトリが管理されます。作業者は、そのサーバーからファイルを取得して作業することができます。CVCSの弱点として、サーバーがないと機能しない点が挙げられます。リポジトリが単一サーバーで管理されているので、サーバーに接続できないような環境では、最新のファイルの取得や版管理をすることができません。

一方、DVCSでは各作業者は自分のローカル環境にリポジトリをミラーリングして作業することができます。各作業者の元にリポジトリが分散している様が分散型と呼ばれる所以なのではないでしょうか。各作業者は、各自のローカル環境で開発を進めて、ローカルのリポジトリで版管理をして、ある程度作業が進んだ段階で、リモートリポジトリに反映することができます。またローカルリポジトリは自分専用のリポジトリであるため、ブランチ作成やコミットがCVCSと比べて気軽に行えます。

## GitHubとは
Gitと関連してよく目にする言葉として[「GitHub」](https://github.co.jp/)というものがあります。GitHubはGitで管理されているレポジトリのホスティングサービスです。

GitHubを通じてレポジトリを公開することで、自分のレポジトリを他者が見ることができるようになり、また自分も他者が公開したレポジトリを見ることができるようになります。

GitHubを用いることで、複数人がコードレビューなどをしながら協働して開発できるようになるのです。

# Gitの仕組み
Gitを理解する上で3つの重要な概念があります。それは、
1. Gitオブジェクト
2. リファレンス
3. インデックス

です。

それでは、これら3つの概念についてもう少し詳しく見ていきましょう。

## Gitオブジェクト
Gitでは、管理するファイルやディレクトリ、それのメタデータであるコミットやタグを「オブジェクト」として扱います。このGitオブジェクトは`Blob` `Tree` `Commit` `Tag`の4種類に分けることができます。

`Commit` `Tag`は文字通りCommitとTagを指します。それ以外の`Blob` `Tree`に関しては、`Blob`がファイルに、`Tree`がディレクトリに対応しています。

Gitオブジェクトは`.git/objects`にて管理されています。
![](https://storage.googleapis.com/zenn-user-upload/6faeaa4a59b9-20230512.png)

画像を見てもらえれば分かる通り、Gitオブジェクトは単なるファイルです。

各Gitオブジェクトには40文字の16進数で表現されたIDが付与されています。このIDはSHA1というハッシュ関数より生成されるハッシュ値です。

IDの先頭2文字がディレクトリ名になり、残りの38文字がファイル名になります。上記の画像を例にすると、`3d97823c91b0bfa9713714c8aef2f3ee0897e969`というGitオブジェクトは、`.git/objects/3d/97823c91b0bfa9713714c8aef2f3ee0897e969`というパスに存在することがわかります。

Gitオブジェクトの中身については、zlibと呼ばれるデータ圧縮ライブラリで圧縮されたデータが入っています。

ここまでで、Gitオブジェクトの中身はzlibで、IDはSHA1で生成されていることが分かりました。では次に、zlibとSHA1に渡す入力について説明します。

zlibとSHA1にわたす入力は`オブジェクトの種類 + [スペース] + データサイズ + [\0](Nullバイト) + データ`になっています。オブジェクトの種類は上で述べた`blob` `tree` `commit` `tag`の4種類です。

以下のsample.txtの場合
```txt:sample.txt
This is a sample text file.
```

入力は
```
blob 27\0This is a sample text file.
```
になります。

gitには`hash-object`という引数に渡したファイルのSHA1ハッシュを計算して表示してくれるコマンドがあります。

```bash
git hash-object test.txt
4aa5f8f4820c61edeed2230683b472358d54598d
```
sample.txtには`4aa5f8f4820c61edeed2230683b472358d54598d`というIDが振られたことが分かります。

<!-- TODO: 画像を入れる -->



入力フォーマットを見てもらえれば分かるのですが、入力はオブジェクトの種類とファイルの中身のみに依存し、ファイルのパスや名前には依存しません。なので、異なるファイルであっても、中身が同一のファイルに関しては、同じIDが振られ、同じGitオブジェクトとして管理されることになります。



## リファレンス
GitではコンテンツがGitオブジェクトとして管理されていて、各GitオブジェクトにはID（SHA1ハッシュ）が振られているのでした。そして、SHA1ハッシュが衝突する確率は極めて低いので、SHA1ハッシュをキーにして、一意にオブジェクトを特定・検索することが可能になっています。

しかし、SHA1ハッシュは40文字の英数字によって表現されていることもあり、人間がオブジェクトのハッシュ値を覚えておくことは面倒であり、SHA1ハッシュをそのまま使うのはあまり実用的ではありません。

その問題を解決する仕組みとして、Gitにはリファレンスというものがあります。それではリファレンスについて見ていきましょう。

### ブランチ
リファレンスは日本語で「参照」という意味です。Gitでのリファレンスの対象は1つ前のセクションで話したコミットオブジェクトです。

リファレンスはファイルで管理されていて、`.git/refs/`ディレクトリ内に存在します。
![](https://storage.googleapis.com/zenn-user-upload/930bbf1ed129-20230517.png)`

リファレンスにも色々種類がありますが、その中の一つの`heads`を取りあげてみましょう。例えば、`heads/main`を見てみると、ファイルにはコミットオブジェクトのSHA1ハッシュが書かれていることが分かります。

```bash
cat .git/refs/heads/main
ccf5cbfb63f1ee509923f968f306bbc552f73742
```

ファイル名mainに見覚えがありますね。そうです、この`headsディレクトリ`配下で管理されているファイルは一般的にブランチと呼ばれるものに当たります。

ブランチという言葉だけを聞くと、枝全体のことを指しているように思えますが、実際のブランチは、枝の末端にあるコミットオブジェクトのハッシュを指しているのです。

あなたが開発者であるならば、ブランチがないことを考えてみてください。わざわざコミットオブジェクトのハッシュ値を覚えておかないと思うと、いかにブランチの存在がありがたいかが分かるかと思います。

### HEAD
リファレンスにはブランチの他に、HEADというものがあります。HEADは分かりやすく言うと、Gitツリー全体の中で、今自分がいる地点を指し示すものです。

HEADは`.git/HEAD`ファイルに書かれています。
![](https://storage.googleapis.com/zenn-user-upload/be928ed0237b-20230519.png)

HEADは`Gitツリー全体の中で、今自分がいる地点を指し示すもの`と言いましたが、実体はブランチのポインタです。

![](https://storage.googleapis.com/zenn-user-upload/ebac9da5e4ac-20230519.png)
HEADファイルの中身を見てみると、ブランチが書かれていることが分かります。

ブランチがコミットオブジェクトのポインタであることを考えれば、HEADはコミットオブジェクトに対するポインタポインタだと言えます。

## インデックス
Gitの仕組みの最後としてインデックスについて説明します。

インデックスはステージングエリアとも呼ばれています。

インデックスがどういった役割なのかを理解するために、gitで管理されているレポジトリの状態を整理します。
![](https://storage.googleapis.com/zenn-user-upload/34b76e61f22e-20230524.png)
この画像のように、`ワーキングディレクトリ` `インデックス` `コミットツリー`の3つの領域に分けることができます。ワーキングディレクトリは作業しているディレクトリでコミットツリーはコミットの履歴です。

インデックスはワーキングディレクトリとコミットツリーの架け橋のような役割を果たしています。

インデックスは`git add`する前であれば、`HEAD`が指しているコミットのスナップショットを表しており、`git add`で修正・追加したファイルを登録した後であれば、次のコミットで反映したいスナップショットを表していると言えます。

そんなインデックスの中身はどうなっているのか気になりますよね。インデックスの中身は`git ls-files -s`で見ることができます。インデックスの中身を覗いてみると、
![](https://storage.googleapis.com/zenn-user-upload/6f94fc58e24a-20230524.png)
- インデックスに登録されているのはBlobオブジェクトだけである
- SHA1ハッシュと共にファイルパスが保存されている
という点に気が付きます。

インデックスの役割、中身については理解できましたが、インデックスがあることでどんな良いことがあるのでしょうか？

理由の一つとして差分検知が楽になるというのが考えられます。

インデックスがなければ、差分検出はブランチが指しているコミットとワーキングディレクトリを比較することになると思うのですが、そうなるとGitオブジェクト（コミット、コミットに含まれるツリーオブジェクト）をzlibで解凍して、バイナリデータを読み込む必要があります。これは少しコストがかかりますよね。

そこでインデックスがあれば、仮に新しいファイルを追加したとすると、その新規ファイルのパスはインデックスに登録されていないので、新しくファイルが追加されたという差分検出が簡単にできます。また、既存ファイルの修正の場合でも、ファイルを修正すればBlobオブジェクトに紐づいたSHA1ハッシュは変わるので、インデックスのパスは同じだけどハッシュ値が異なる行がヒットし、ファイルに修正が加えられたことが検知できるので


# まとめ
自作Gitの実装内容についての解説に先立ち、Gitの概要と仕組みについて書きました。

Goitの実装内容については記事にして後日公開する予定なので、もしよかったらそちらも読んでみてください。

また、今後も「Goit」の開発を進めるていくつもりなので、レポジトリにスターを付けてくださると励みになります。

https://github.com/JunNishimura/Goit

# 参考資料
#### ＜Gitについて＞
- [Git とは何か](https://www.atlassian.com/ja/git/tutorials/what-is-git)
- [集中型バージョン管理システムと分散型バージョン管理システムって](https://hyoshiok.hatenablog.com/entry/20140205/p1)
- [GitとSubversionの構造的な違い｜GitのブランチはSubversionのブランチとは全く違うモノ](https://www.ricksoft.jp/blog/articles/001410.html)

##### ＜Gitの仕組みについて＞
- [Git の仕組み (1)](https://koseki.hatenablog.com/entry/2014/04/22/inside-git-1)
- [Git の仕組み (2) - コミット・ブランチ・タグ](https://koseki.hatenablog.com/entry/2014/06/11/inside-git-2#f-4373775d)
- [Gitのインデックスの中身](https://zenn.dev/kaityo256/articles/inside_the_index)
- [Gitのブランチの実装](https://zenn.dev/kaityo256/articles/inside_the_branch)
- [Gitのオブジェクトの中身](https://zenn.dev/kaityo256/articles/objects_of_git)
- [GitのHEADとは何者なのか](https://qiita.com/ymzkjpx/items/00ff664da60c37458aaa)
- [たぶんもう怖くないGit ~Git内部の仕組み~](https://qiita.com/marchin_1989/items/2ec01553e907f3a9e6bb#fn-3)
- [コミットはスナップショットであり差分ではない](https://github.blog/jp/2021-01-06-commits-are-snapshots-not-diffs/)
- [コマンドを使わずに理解するGit](https://qiita.com/noshishi/items/2821c01d590bf9c96038)
- [Gitを作ってみる（理解編）](https://qiita.com/noshishi/items/60a6fe7c63097950911b)
- [Gitが連想配列記憶装置であることを低レイヤーな操作を通して体感しよう！](https://qiita.com/DQNEO/items/0233a680b0f9471db9ee)
- [Git が内部でデータを取り扱う方法](https://zenn.dev/username/articles/2022-09-19-8118755d3cd9291907ee)
- [Gitの内側](https://git-scm.com/book/ja/v2/Git%E3%81%AE%E5%86%85%E5%81%B4-%E9%85%8D%E7%AE%A1%EF%BC%88Plumbing%EF%BC%89%E3%81%A8%E7%A3%81%E5%99%A8%EF%BC%88Porcelain%EF%BC%89)
- [Git Internals part 1: The git object model](https://dev.to/calebsander/git-internals-part-1-the-git-object-model-474m)
- [What does the git index contain EXACTLY?](https://stackoverflow.com/questions/4084921/what-does-the-git-index-contain-exactly)
- [What is the internal format of a Git tree object?](https://stackoverflow.com/questions/14790681/what-is-the-internal-format-of-a-git-tree-object)

##### ＜Gitの実装について＞
- [Rustで自作Git作った話](https://zenn.dev/garebare/articles/8bd5d66003dd6e)
- [Gitを作ってみる（開発編）](https://qiita.com/noshishi/items/823bc46d971ac1fe8215)
- [Goの固定長/可変長エンコーディングを理解する](https://zenn.dev/nakabonne/articles/cc0cde2bd94639)
- [【mixi】ハンズオン: 内部構造を学びGitを自作できるようになろう！](https://www.youtube.com/watch?v=-4rcs6SgT0o)