← Gitの内部構造から理解する コース
7. git add の正体 — ステージは「次のtreeの下書き」
新卒がまず戸惑うのが「なぜcommitの前にaddが要るのか」です。内部構造から見ると、addとcommitはまったく別の仕事をしています。
① addとcommitの分担
作業ツリーあなたが編集するファイル
git add — 中身をblobにしてDBへ入れ、一覧に載せる
ステージ(index)パス → blobハッシュ の一覧
git commit — 一覧からtreeを組み立て、commitで包む
tree + commitオブジェクトDBへ
- ・addの時点でblobは既にDBに入っている(commitを待たない)
- ・ステージは「次のコミットのtreeをどう組むか」の下書き
- ・commitはステージの内容だけを見る。作業ツリーは見ない
「addを忘れてcommitしたら変更が入っていなかった」という失敗は、commitがステージだけを見ているためです。
② addした後にさらに編集するとどうなるか
作業ツリー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つの具体例で確認します。
公式ドキュメントで詳しく ↗