【仕組み解説】Gitはどうやってファイルの履歴を管理しているのか — 内部構造を図解

いい質問だね。Gitの正体は、プロジェクトフォルダの中にある「.git」っていう隠しフォルダなんだ。この中にファイルの全履歴がデータベースのように保存されてるんだよ。

一番大事なのは「objects」フォルダだよ。Gitは3種類のオブジェクトでファイル履歴を管理してるんだ。まず「blob」はファイルの中身そのもの。「tree」はフォルダ構造を表していて、どのblobがどのファイル名かを記録してる。そして「commit」はtreeのスナップショットに、作成者や日時、コミットメッセージを付けたものだよ。

そうなんだ。しかもすべてのオブジェクトはSHA-1ハッシュっていう40文字の英数字で識別されてるよ。ファイルの中身が同じなら必ず同じハッシュになるから、重複を自動的に排除できるし、データが壊れてないかも検証できる。git logで見える「a1b2c3d...」みたいなのがまさにこのハッシュだね。

鋭いね！ブランチの正体はただの「ポインタ」なんだ。特定のcommitオブジェクトのハッシュを指し示すだけのテキストファイルだよ。.git/refs/heads/mainを覗くと、40文字のハッシュが1行書いてあるだけ。だからブランチの作成は一瞬で、ディスク容量もほぼ使わないんだ。

HEADは「今どのブランチにいるか」を示すポインタだよ。.git/HEADファイルの中身は「ref refs/heads/main」のように、現在チェックアウトしているブランチへの参照が書かれてる。ブランチを切り替えると、この参照先が変わるだけなんだ。

マージには主に2種類あるよ。「fast-forward」は、取り込み先が一直線上にあるとき、ブランチのポインタをそのまま先に進めるだけ。新しいコミットは作られない。一方「3-way merge」は、2つのブランチが分岐してるとき、共通の祖先コミットと両方の最新コミットの3つを比較して、新しい「マージコミット」を作るんだ。

rebaseは「ブランチの根元を付け替える」操作だよ。分岐元のコミットを最新に変更して、自分のコミットを一つずつ作り直すんだ。結果として履歴が一直線になってきれいになるけど、コミットのハッシュが全部変わるから、共有済みのブランチでやると他の人と衝突する。個人の作業ブランチで使うのが安全だね。

そんなときはreflogが助けてくれるよ。「git reflog」を実行すると、HEADが過去に指していたコミットの履歴が全部見られるんだ。resetやrebaseで消えたように見えるコミットも、reflogにはしばらく残ってる。「git reset --hard HEAD@(2)」のように指定すれば復元できるよ。

そうだね。Gitの内部はたった3種類のオブジェクトとハッシュ、そしてポインタというシンプルな仕組みの組み合わせなんだ。この基本を理解しておくと、ブランチ操作やマージで何が起きてるか見えてきて、トラブルの対処もずっと楽になるよ。