Dev Study
← Gitの内部構造から理解する コース

7. git add の正体 — ステージは「次のtreeの下書き」

新卒がまず戸惑うのが「なぜcommitの前にaddが要るのか」です。内部構造から見ると、addとcommitはまったく別の仕事をしています。

① addとcommitの分担

2つのコマンドがそれぞれ何を作るか
作業ツリーあなたが編集するファイル
git add — 中身をblobにしてDBへ入れ、一覧に載せる
ステージ(index)パス → blobハッシュ の一覧
git commit — 一覧からtreeを組み立て、commitで包む
tree + commitオブジェクトDBへ
  • ・addの時点でblobは既にDBに入っている(commitを待たない)
  • ・ステージは「次のコミットのtreeをどう組むか」の下書き
  • ・commitはステージの内容だけを見る。作業ツリーは見ない

「addを忘れてcommitしたら変更が入っていなかった」という失敗は、commitがステージだけを見ているためです。

② addした後にさらに編集するとどうなるか

同じファイルの3つの姿
作業ツリーversion 3(最新の編集)
ステージversion 2(addした時点)
最新コミットversion 1
この状態で commit すると
version 2 が記録されるversion 3 は入らない
  • ・git status が同じファイルを2箇所に表示するのはこのため
  • ・「Changes to be committed」= ステージ、「Changes not staged」= 作業ツリー
  • ・最新の編集を入れたければ、もう一度 git add する

1つのファイルが同時に3つの姿を持ちうる、というのがGitの状態管理です。ステージという中間層があることで、変更を選んでコミットできます。

サンプルコードで身につける(5本) →

学んだ概念を、素朴な例から実務寄りの例まで5つの具体例で確認します。

公式ドキュメントで詳しく ↗