女性向けエンジニアスクール
3秒でわかる
Git で次のコミットに含める変更を選んで置いておく作業台。編集中のファイルと確定した履歴の間にある、中間の置き場を指します。
もう少し詳しく
どういうものか
Git で、次のコミットに含める変更を一時的に登録しておく領域。インデックスやステージングエリアとも呼ぶ。git add を実行するとファイルの変更がここに載り、git commit を実行すると載っているものだけが履歴として確定する。
Git のファイルは 3 つの場所を移動する。編集中の作業ディレクトリ、次のコミット候補が並ぶステージ、確定した履歴を保持するリポジトリの 3 つになる。git status の出力が 2 つの見出しに分かれているのは、この 2 段構えを表している。
なぜ必要か
作業をしていると、1 回の編集の中に無関係な変更が混ざる。バグ修正のついでに設定値を変えた、デバッグ用の出力を足した、といった具合になる。全部まとめてコミットすると、あとで履歴を追う人が「この修正はどれか」を判断できない。ステージがあると、関係する変更だけを選んで 1 コミットにまとめられる。
具体例
git status # 変更されたファイルの一覧を見る
git add src/login.js # 1ファイルだけ載せる
git add src/ # ディレクトリごと載せる
git add -p # 同じファイルの中の一部だけを選んで載せる
git diff # まだ載せていない変更を見る
git diff --staged # 載せた変更を見る
git restore --staged src/config.js # 載せたものを降ろす（編集内容は残る）
git commit -m "ログイン失敗時のメッセージを修正"git add -p は変更のかたまりごとに載せるかどうかを聞いてくるため、1 つのファイルに混ざった 2 種類の修正を別々のコミットに分けられる。
つまずきやすいところ
git add したあとにさらに編集した場合、コミットされるのは add した時点の内容になる。あとから書き足した分は載っていない。同じファイル名が「変更あり」の欄と「コミット予定」の欄の両方に出ていたら、この状態になっている。
git commit -a は、追跡済みファイルの変更を自動で載せてからコミットする。手軽な反面、選り分けの利点が消える。
git restore --staged と git restore の違いも間違えやすい。前者は降ろすだけで編集内容は残るが、後者はファイルの編集そのものを捨てる。
覚え方
買い物かごに入れる操作が git add、レジで会計するのが git commit。かごに入れただけなら、棚に戻せる。