📌 この記事は Zenn に投稿した内容のアーカイブです。

はじめに

Git を使っていて、こんな感覚になったことはありませんか？

• コマンドは打てるけど、何が起きているか分からない

• merge と rebase の違いを、説明しろと言われると詰まる

• conflict が出ると、なぜ衝突したのか理解できない

多くの Git 解説記事は、
「何を打つか」 は丁寧に教えてくれますが、
「なぜそうなるか」 までは踏み込んでくれません。

その結果、

なんとなく使えているが、仕組みはよく分からない

という状態に陥りがちです。

この記事では、コマンドの説明はほぼ行いません。
代わりに、Git の内部構造をデータ構造として捉え直す ことで、

「あ、そういうことだったのか」

と腑に落ちる理解を目指します。

少しだけ グラフ理論 と ポインタの概念（C 言語） の素養があると、
かなりスムーズに理解できると思います。

Git の正体：木構造ではなく DAG（有向非巡回グラフ）

多くの人は、Git の履歴を「木構造」としてイメージしています。

しかし、これは正確ではありません。

Git の本質は 有向非巡回グラフです。

Commit は「ノード」

すべての commit は、グラフ上の ノード です。

各 commit は、

• ファイルのスナップショット

• 親 commit への参照（1 個または 2 個）

を持っています。

親が 2 個になる瞬間 = merge

通常の commit は親が 1 つですが、
merge commit は 親を 2 つ 持ちます。

この構造によって、Git の履歴は 木ではなく DAG になります。

branch と HEAD の正体は「ただのポインタ」

Git を難しく感じさせている最大の原因は、
branch という言葉のイメージです。

多くの人は branch を「分岐した別ルート」だと考えますが、
実際にはこうです：

branch は単なる commit へのポインタ

branch = 名前付きポインタ

main -> C5

これは、

「main という名前が commit C5 を指している」

という意味でしかありません。

branch 自体には、履歴も構造も存在しません。

HEAD は「ポインタへのポインタ」

さらに混乱を招く存在が HEAD です。

HEAD は commit を直接指しているのではありません。

HEAD -> branch -> commit

つまり、

HEAD は branch を指すポインタ

です。

たとえば：

HEAD -> main -> C5

この状態で commit すると、

1. 新しい commit C6 が生成される

2. main が C6 を指す

3. HEAD は引き続き main を指す

という 極めて単純なポインタ操作 が行われています。

Git の操作を「ポインタ操作」として捉える

ここまで理解できると、Git の各コマンドは
すべて ポインタの付け替え として説明できます。

git init

空の DAG を生成するだけ
まだ commit は 1 つも存在しない

git clone

他人の DAG を丸ごとコピーしてくる

ローカルとリモートの構造は 完全に同一 です。
唯一の違いは：

リモート branch には origin/ という接頭辞が付く

だけです。

git add

ファイル差分を HEAD に記録する

commit ではありません。
あくまで 「次の commit に含める差分を HEAD に積む」 操作です。

※ 正確には index は次コミットのスナップショットであり、
git add は差分を積むというより、そのスナップショットを更新している。

git commit

HEAD が保持している差分を使って、新しいノードを生成する
そして branch をそのノードへ移動させる

git reset

branch の指す commit を、別のノードへ付け替える

履歴を書き換えたように見えるのは、
ポインタを過去へ動かしているだけ です。

git checkout

HEAD が指す branch を切り替える

つまり、

HEAD -> main
HEAD -> dev

の付け替え操作に過ぎません。

git push / pull が分かりにくい理由

push / pull が分かりづらい原因も、
「構造を見ていない」ことにあります。

本質はこれだけ

ローカルとリモートの branch が、
どの commit を指しているかの問題

fast-forward とは？

ローカルとリモートの commit が 同一の履歴線上 にある場合：

A - B - C - D
        ↑
      remote

A - B - C - D - E - F
                ↑
              local

このとき push すると：

• E, F をリモートへコピー

• リモート branch を F へ移動

これが fast-forward です。

merge が発生する条件

両者の履歴が 分岐している場合 ：

      D - E   (local)
     /
A - B - C
     \
      F - G   (remote)

この場合、

どちらの先に進むべきか自動で決められない

ため、merge commit を生成 します。

rebase の正体：枝を「付け替える」だけ

rebase は難しく感じられがちですが、
構造としてはとても単純です。

      D - E   (local)
     /
A - B - C
     \
      F - G   (remote)

これを rebase すると：

A - B - C - F - G - D - E

やっていることは：

共通祖先以降のローカル側の枝を切り落とし、
そのまま相手の先端につなぎ直す

だけです。

※ 内部的には commit を付け替えるのではなく、差分を再適用した新しい commit を生成している。

conflict の正体

conflict が発生する条件も非常に明快です。

同一 commit 祖先から分岐し、
同じファイルの同じ行を、別々に変更した

この場合、Git は：

「どちらが正しいか判断できない」

ため、人間に決断を委ねる だけです。

構造的には、
「新しい commit を作る前に、人力で差分解決を要求されている」
という状態です。

すべては DAG とポインタ操作

ここまで見てきた通り、Git のすべての挙動は：

• DAG 構造

• ポインタの付け替え

この 2 つで 完全に説明可能 です。

コマンドを丸暗記するよりも、

「今、どのポインタがどこを指しているのか」

を意識する方が、
圧倒的にトラブル対応力が上がります。

まとめ：Git は難しくない、見えづらいだけ

Git は決して複雑なツールではありません。

難しく感じる理由はただ一つ：

内部構造が可視化されていないから

です。

DAG とポインタ構造で理解できた瞬間、

• branch

• HEAD

• merge

• rebase

• reset

• checkout

これらはすべて
自然に説明できる単純操作 に変わります。

もし今まで Git を「なんとなく」使っていたなら、
ぜひ一度、構造から考える視点 を持ってみてください。

おそらく、
Git に対するストレスが一段階、確実に下がるはずです。