変更の一部だけをコミットする：git add -pで二つの修正を分ける

文字色の修正は完成したけれど、同じCSSに書いた余白の試作は残しておきたい。ファイル全体をgit addすると、両方が次のコミットへ入ります。変更の一部だけをコミットするには、ファイルの中の差分を選んでステージします。

Gitのaddとcommitを使ったことがある人向けです。Git 2.50.1で使えるコマンドと、macOSやLinuxなどのシェルを使います。架空の作品案内のCSSを、空の新しい練習フォルダで扱います。既存の仕事用リポジトリへ貼り付けず、練習ではリモートへの送信も行いません。

手元のファイルと、次に記録する内容は別に持てる

ステージ領域、別名インデックスは、次のコミットへ入れる内容を準備する場所です。最後のコミットであるHEAD、インデックス、手元で編集する作業ツリーの三つを区別すると、一部だけ追加する操作を追えます。

作りたいのは真ん中の状態です。手元のCSSを元へ戻してからコミットする必要はありません。git addの公式資料にある-pを使い、選んだ変更だけをインデックスへ移します。

ただし、ステージはファイル名に付く予約の印ではありません。追加した時点の内容が準備されます。後から文字色をもう一度変えた場合、その変更は再度追加するまで次のコミットに入りません。ファイルを見て「直っている」と判断するだけでは不十分です。

二つの修正が離れたCSSを用意する

まだ存在しないフォルダ名を使い、次をターミナルで実行します。同名の練習フォルダがあるなら別名にしてください。最初に記録するCSSでは、文字色と余白の間に未変更の規則を置き、差分の塊が二つに分かれるようにしています。

mkdir git-stage-practice
cd git-stage-practice
git init
cat > style.css <<'CSS'
.title { color: #777; }

/* 共通の本文 */
.body {
  font-size: 16px;
  line-height: 1.8;
  max-width: 40rem;
  margin: auto;
}

/* 余白の試作箇所 */
.card { padding: 8px; }
CSS
git add -- style.css
git -c user.name=Practice -c user.email=practice@example.invalid commit -m "Add practice styles"

名前とメールはこの練習コミットだけの指定です。全体のGit設定は変えません。次にエディターでstyle.cssを開き、#777を#222へ、8pxを24pxへ変更して保存します。他の行はそのまま残します。

git diff -- style.css
git add -p -- style.css

差分には削除側の行がマイナス、追加側の行がプラスで表示されます。差分の塊をhunkと呼びます。文字色の塊が出たらyとEnter、余白の塊が出たらnとEnterを入力します。順序だけで答えず、毎回プラスとマイナスの行を読んで選んでください。

表示される質問の文言や色はGitの設定で変わります。二つが一つの塊として表示され、選択肢にsがある場合は、sで小さく分けてから選べます。誤って全部選ぶaを使わず、判断できなければqで残りを選ばず終了します。qで、それまで選んだ変更まで取り消せるわけではありません。

二種類のdiffで、色と余白の行き先を照合する

選択後は次の二つを、続けて読みます。

git diff --cached -- style.css
git diff -- style.css

一つ目には#777から#222への変更だけ、二つ目には8pxから24pxへの変更だけが出るのが正解です。git diffの公式資料では、--cachedが最後のコミットとステージを比べ、指定なしではステージと作業ツリーを比べることを確認できます。

前後の文脈として未変更の行も表示されるため、余白の文字が画面に一度でも現れたら失敗、という読み方はしません。変更されたプラス・マイナスの行で判定します。両方の差分を見れば、入れた変更と残した変更の対応が取れます。

さらにgit show :style.cssでステージ側のファイル全体を読めます。ここでは文字色が#222、余白が8pxの完成状態になっているはずです。実際の機能修正では、こうして取り出した版だけでも必要な依存関係がそろうか検証します。手元の完成形で動くことは、分割したコミットが動くことと同義ではありません。

選びすぎた場合と、追加後に直した場合

一つ目の失敗は、誤ってgit add -- style.cssで両方を追加することです。--cachedに余白変更も出ます。今回のように最初はステージが空だった練習なら、次でこのファイルのステージを外し、-pから選び直せます。

git restore --staged -- style.css
git diff --cached -- style.css
git diff -- style.css

一つ目のdiffは空、二つ目は色と余白の両方になります。git restoreの--stagedの説明に従い、戻すのはインデックスだけです。--stagedを省いたり--worktreeを足したりすると、手元の編集を戻す操作になるため、この手順では変更しません。先に別の人が準備した差分がある場合も、ひとまとめに外さないでください。

二つ目は、色を選んだ後で#222を#333へ直し、追加し直さずコミットする失敗です。手元の色が新しくても、ステージは#222のままです。修正では再び-pを実行して#222から#333の色変更だけを選びます。--cachedが#777から#333、指定なしのdiffが余白だけになったか再確認します。

この追加実験をした場合は、本文の最初の解答へ戻る前に色を#222へ直し、その変更も-pで追加します。最終的に次の節で記録する色は#222です。どの操作をしたか曖昧なら、コミットより先にステージ側のファイルを読み直してください。

一緒に成立する変更は、無理に分けない

文字色の訂正と独立した余白の試作なら、今回のように目的で分けられます。一方、新しいクラス名へ変更するHTMLと、そのクラスのCSSは、片方だけでは表示が崩れる場合があります。ファイルが違うことや、別のhunkであることは、独立した修正である根拠にはなりません。

細分化の単位は「そのコミットだけで説明・確認できる変更」です。隣り合う二行が分割できないときに、いきなりパッチを手編集するより、まず変更の目的が本当に分けられるかを見直します。今回扱うのは追跡済みのテキストです。新規ファイル、画像、競合中の状態は別の操作が必要になります。

.gitignoreと追跡状態の記事は、そもそも追跡するかを決める内容です。未完成の余白だけを今回のコミットから外す目的で、style.css自体を除外する必要はありません。レビュー依頼の書き方へ進むときは、今回入れた色変更を短く説明できます。

コミット後にも、試作が手元に残るか

15〜20分を目安に、二つのdiffが期待どおりになったところで、練習の色変更を記録します。-aやファイル名付きのcommitは使わず、準備済みの内容をそのまま記録します。

git -c user.name=Practice -c user.email=practice@example.invalid commit -m "Adjust title color"
git show HEAD:style.css
git diff -- style.css
git diff --cached -- style.css

合格条件は三つです。HEAD側は色#222・余白8px、未ステージの差分には余白8pxから24pxへの変更だけが残り、ステージ済みの差分は空になります。エディターのCSSでは余白24pxも残ります。変更一覧が空でなくても、狙った分割はできています。公開・運用の無料レッスンへ進む前に、手元の試作と記録した版を区別して説明してください。