「git commit」の裏側で何が起きているか？ Gitのオブジェクトモデルを徹底解剖し、.gitディレクトリの「心臓部」を理解する

Gitの内部構造とオブジェクトモデル：リポジトリの心臓部を解剖する

1.0 はじめに：なぜGitの内部を知るべきか

現代のソフトウェア開発において、Gitは不可欠なインフラです。日常的な git commit や git push の操作に習熟することはもちろん重要ですが、一歩踏み込んでその内部でデータがどのように構成・管理されているかを理解することは、プロの開発者として極めて戦略的な意味を持ちます。

この技術レポートは、Gitの日常的な使用方法ではなく、その心臓部である .git ディレクトリ内の実装に焦点を当てます。

💡 本レポートの目的:

1. .git ディレクトリの構造、Gitオブジェクト、参照、インデックスという4つの主要概念を明確に解説します。
2. 「全てのソフトウェアには実装がある」という感覚を養い、ツールの挙動を根本から理解するための強固な基盤を提供します。
3. 専門的かつ公式なトーンで、プロの開発者を対象に記述します。

まず始めに、Gitリポジトリの全情報を格納する .git ディレクトリの構造から、内部の探求を開始します。

2.0 .gitディレクトリの構造：Gitリポジトリの心臓部

Gitリポジトリの全情報は、ワーキングツリー（私たちが日常的に操作するファイル群）とは別に、プロジェクトのルートに存在する .git という単一のディレクトリに集約されています。このディレクトリが、リポジトリの完全な履歴、設定、参照情報を保持しています。

ls .git コマンドの出力例は以下の通りです。

COMMIT_EDITMSG HEAD branches/ config description hooks/ info/ index logs/ objects/ packed-refs ORIG_HEAD FETCH_HEAD refs/

これらの構成要素の中でも、Gitの核心的な機能を担う主要なファイルとディレクトリの役割を以下にまとめます。

ファイル/ディレクトリ名	概要
HEAD	カレントブランチ（現在の作業場所）の情報を保存するファイル。
index	インデックス（ステージングエリア） の情報を保存するバイナリファイル。
config	リモートリポジトリ、上流ブランチなどの設定情報を保存するファイル。
objects/	コミット、ファイル内容などの全オブジェクトを保存するディレクトリ。
refs/	ブランチ、タグといった参照情報を保存するディレクトリ。

特に、リポジトリのデータ本体を格納する objects/ ディレクトリは、Gitの効率性と堅牢性の核心です。次章では、このオブジェクトモデルについて詳述します。

3.0 Gitの心臓部：オブジェクトモデル

Gitのデータ管理モデルは、その効率性と堅牢性の中核をなす**「内容アドレス可能ファイルシステム (content-addressable filesystem)」という強力な概念に基づいています。Gitは、管理下にある全てのコンテンツと履歴を「オブジェクト」**と呼ばれるデータ単位として保存します。

3.1 Gitオブジェクトの4分類

Gitが管理するオブジェクトは、以下の4種類に大別されます。

1. Blob (Binary Large Object): ファイルの内容そのものに相当します。
2. Tree: Blobオブジェクトや他のTreeオブジェクトを管理し、ディレクトリ構造に相当します。
3. Commit: Treeオブジェクトを包み込み、親コミットやコミットメッセージなどの文脈情報を付与します。各スナップショットに対応します。
4. Tag: コミットオブジェクトなどを対象とし、タグ付与者やタグメッセージを付加します。

3.2 📄 Blobオブジェクト：ファイル内容の保存

Blobオブジェクトは、Gitにおけるファイル内容の基本的な保存単位です。Gitはファイル名ではなく、ファイルの内容そのものを管理します。

SHA-1ハッシュによる識別

Gitの全てのオブジェクトは、その内容から計算される SHA-1ハッシュ値（160ビット/16進数40桁）によって一意に識別されます。

• 決定性: 同じ入力からは常に同じハッシュ値が生成されます。
• 感度: 入力がわずかでも変化すると、ハッシュ値は大きく変動します。
• 物理的な保存:
  • ハッシュ値: e51ca0d0b8c5b6e02473228bbf876ba000932e96
  • 保存パス: .git/objects/e5/1ca0d0b8c5b6e02473228bbf876ba000932e96
  • ハッシュの最初の2文字がディレクトリ名、残りの38文字がファイル名として格納されます。

Blobオブジェクトの定義

Blobオブジェクトは、ファイルの内容に以下のヘッダを付与し、全体をzlibで圧縮したバイナリデータです。

$$\text{ヘッダ} = \text{"blob"} + \text{スペース} + \text{ファイルサイズ（バイト数）} + \text{ヌル文字}$$

ハッシュ値は、このヘッダが付与された内容全体に対して計算されます。この仕組みにより、Gitはデータの一貫性と完全性を保証し、ファイル名変更時のデータ重複を防いでいます。

3.3 Treeオブジェクト：ディレクトリ構造のスナップショット

Treeオブジェクトは、特定の時点におけるプロジェクトの**ディレクトリ構造（スナップショット）**を表現します。ファイルシステム上のディレクトリに相当します。

内部構造の分析

Treeオブジェクトは、内部にBlobオブジェクト（ファイル）や他のTreeオブジェクト（サブディレクトリ）への**参照（ポインタ）**をリスト形式で保持します。

$ git cat-file -p <tree-hash>
100644 blob e51ca0d0b8c5b6e02473228bbf876ba000932e96    test.txt
040000 tree 8a7f4c7f9d0c6b1a2e3b4f5d6c7e8a9b0c1d2e3f    src

各行は以下の情報で構成されます。

• モード: ファイルのパーミッション情報（例: 100644は通常ファイル、040000はディレクトリ）。
• タイプ: blob（ファイル）か tree（ディレクトリ）か。
• ハッシュ: 対応するオブジェクト（BlobまたはTree）のSHA-1ハッシュ。
• 名前: ファイル名またはディレクトリ名。

この再帰的な参照構造により、Gitはプロジェクト全体の階層構造を、データの実体を複製することなくポインタの集合として効率的に記録できます。

3.4 Commitオブジェクト：変更履歴の連結

Commitオブジェクトは、Treeオブジェクトが表現するスナップショットに文脈情報を付与し、プロジェクトの履歴を時系列に連結する極めて重要な役割を果たします。

Commitオブジェクトの内部構造

git commit 実行時、インデックスの状態からTreeオブジェクトが生成され、次にそのTreeを参照するCommitオブジェクトが作成されます。

$ git cat-file -p <commit-hash>
tree dd1d743a1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d
parent ca70291e9f8d7c6b5a4f3e2d1c0b9a8f7e6d5c4b
author John Doe <[e-mail]> 1635724800 +0900
committer John Doe <[e-mail]> 1635724800 +0900

Initial commit: Added test.txt

• tree: このコミットが記録するルートTreeオブジェクトのハッシュ。
• parent: 直前のコミットのハッシュ。このポインタ機構が、プロジェクトの全履歴を表現する**有向非巡回グラフ（DAG）**を構築します。
  • 最初のコミット（ルートコミット）にはこの行は存在しません。
• author / committer: 開発者情報とタイムスタンプ。
• コミットメッセージ: 変更内容の説明。

マージコミットの特徴

マージコミットは parent を複数（通常は2つ）持ちます。これは、分岐した開発ラインがどのように合流したかを履歴上に明確に記録するサインです。

4.0 状態の追跡：参照とインデックス

Gitオブジェクトは不変のデータストアを形成しますが、開発の進行に合わせて変化する「現在の作業場所」や「最新状態」を追跡するためには、可変のポインタが必要です。これが「参照（refs）」です。

4.1 Git参照の物理的実装

ブランチやHEADといった抽象的な概念は、.git ディレクトリ内の驚くほど単純なテキストファイルとして実装されています。

概念	実体パス	内容
main ブランチ	.git/refs/heads/main	最新のコミットのSHA-1ハッシュ（1行）
HEAD	.git/HEAD	ref: refs/heads/main （ブランチへの参照）
origin/main	.git/refs/remotes/origin/main	リモート追跡ブランチの最新コミットハッシュ

高速性の秘密

ブランチの作成や切り替えが他のVCSと比較して圧倒的に高速である理由は、これが高価なデータベース操作ではなく、単なる41バイトのファイル書き込みに過ぎないからです。

Detached HEAD（分離HEAD）状態

HEAD が特定のブランチではなく、特定のコミットハッシュを直接指している状態です。このとき、.git/HEAD ファイルの中身はブランチへの参照ではなく、コミットハッシュそのものになります。

4.2 インデックス（ステージングエリア）の役割

インデックス（ステージングエリア）は、ワーキングツリーとリポジトリのコミット履歴との間に位置する、次回のコミット内容を準備するための重要な中間領域です。

• 物理的な実体: .git/index という単一のバイナリファイルです。
• 内容: 基本的にファイルパスとそれに対応するBlobオブジェクトのハッシュのリストです。

$ git ls-files --stage
100644 e32836f... 0  file_a.txt
100644 363d8b7... 0  test.txt

このリストが、次回のコミットに含まれる**「スナップショットの設計図」**です。

• git add コマンドは、ワーキングツリーの内容からBlobオブジェクトを生成し、このインデックスにそのハッシュを登録します。
• git commit コマンドは、このインデックスの状態からのみTreeオブジェクトを構築します。

この仕組みがあるからこそ、git add -p のように、ファイル全体ではなく変更の一部だけをコミットに含めるという柔軟な操作が可能になるのです。

5.0 結論：内部構造の理解がもたらす力

Gitの内部構造を構成する主要な要素（オブジェクト、参照、インデックス）が、いかに単純かつ素直な概念の組み合わせで構築されているかを詳細に解説しました。

要点

要素	役割	実装の特性
オブジェクト (objects/)	データ本体（ファイル内容、ディレクトリ構造、履歴）を保存。	不変。SHA-1ハッシュでアドレス指定。
参照 (refs/)	ブランチ、HEADなどの最新状態を追跡。	可変。コミットハッシュが記述された単純なテキストファイル。
インデックス (index)	ワーキングツリーとコミット履歴の中間に位置する「ステージングエリア」。	バイナリファイル。次のコミットの設計図を保持。