第3回| git add と git commit で変更を選んで記録する | 2ステップに分かれている理由をやさしく整理する｜UNIX Cafe

Git 入門 | 第３回

Git で変更を記録するとき、なぜ git add と git commit の 2 ステップが必要なのでしょうか。最初は「まとめて 1 つでよいのでは」と感じる方も多いと思います。でもこの 2 つが分かれていることには、ちゃんと理由があります。

今回は git add と git commit をセットで整理します。それぞれの役割、実際の出力の読み方、よくあるつまずきポイントまで、順を追って見ていきます。

📝 この記事で学べること

• git add と git commit それぞれの役割
• なぜ 2 ステップに分かれているのか
• 実際のターミナル出力の読み方
• コミットメッセージの書き方と考え方
• 初心者がつまずきやすいポイントと対処

2 ステップの全体像をまず見ておく

最初に流れ全体を確認します。

add は「記録する」ではなく「記録の候補にのせる」操作です。commit して初めて、あとから見返せる履歴になります。

git add | 今回残したい変更を選ぶ

たとえば 3 つのファイルを編集したとします。そのうち今回まとめて記録したいのは 1 つだけ、残り 2 つはまだ作業中、という場面はよくあります。

そんなとき、git add で記録したいファイルだけを選べます。

git add notes/today.txt

git add notes/today.txt

この時点ではまだ履歴には残っていません。「今回はこの変更を記録対象にしたい」と Git に伝えた段階です。

全ファイルをまとめて選びたい場合は、次のように書きます。

git add .

git add .

ただし、作業中のものが混ざらないよう、git status で状態を確認してから使う習慣をつけると安心です。

git add したあとの出力を読む

git add 自体は、成功しても何も表示されません。「何も出なかったけど大丈夫？」と不安になりやすいですが、これは正常な動作です。確認したいときは git status を使います。

git status

git status

add したあとに git status を実行すると、次のような表示になります。

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   notes/today.txt

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   notes/today.txt

各行の意味はこうです。

Changes to be committed: の欄にファイルが表示されていれば、add は正しく通っています。

git commit | 選んだ変更を履歴として残す

add で選んだ変更を、履歴として確定させるのが git commit です。

git commit -m "今日のメモを更新"

git commit -m "今日のメモを更新"

うまくいくと、次のような出力が表示されます。

[main a1b2c3d] 今日のメモを更新
 1 file changed, 3 insertions(+), 1 deletion(-)

[main a1b2c3d] 今日のメモを更新
 1 file changed, 3 insertions(+), 1 deletion(-)

各行の意味はこうです。

ここで Git が行うのは、ファイルの上書きではありません。「この変更をいつ、どんな目的で加えたか」という記録を履歴に追加する操作です。

コミットメッセージの書き方

コミットメッセージは、あとで履歴を見返したときに「この記録は何だったのか」を教えてくれる一言です。自分だけが使うローカル作業であっても、数週間後の自分が読んで分かる内容を書いておくと助かります。

良いメッセージと、そうでないメッセージの違いを見てみましょう。

日本語でも英語でも構いません。大切なのは、「何のための変更か」が一言で伝わることです。最初は短くても、具体的な内容を書く習慣をつけるだけで十分です。

なぜ 2 ステップに分かれているのか

「add と commit をなぜ分けるのか」という疑問は、Git を学び始めたほぼ全員が感じるところです。理由は、変更を意味のある単位で整理して残すためです。

たとえば、バグ修正とメモの追記を同時に行ったとします。この 2 つを 1 つのコミットにまとめると、あとで履歴を見たときに「この記録は何の変更だったのか」が分かりにくくなります。

add で先にバグ修正だけを選んで commit し、次にメモの追記を選んで別の commit にする。こうすると、2 つの変更がそれぞれ独立した記録として残ります。小さく分けて残すほど、あとから見返したときに何がどこで変わったかを追いやすくなります。

初心者がつまずきやすいポイント

実際に操作してみると、いくつか「あれ？」となりやすい場面があります。あらかじめ知っておくと慌てずに済みます。

add したのに変化がない

これは正常な動作です。add は選ぶだけで、記録するのは commit の役割です。add のあとに commit を忘れると変更は宙に浮いたままになります。git status で Changes to be committed: の欄を確認してみましょう。

-m をつけ忘れてエディタが開いた

git commit と打つと、メッセージを書くためのエディタが開きます。vi が起動した場合は i で入力モードに入り、メッセージを書いて Esc → :wq で保存して閉じます。慣れないうちは -m "メッセージ" をセットにして覚えておくと扱いやすいです。

nothing to commit と表示された

add していない状態で commit しようとすると、nothing to commit, working tree clean と表示されます。記録する対象がないという意味です。先に git add で変更を選んでから commit する順番を確認しましょう。

add から commit までの流れを確認する

実際の操作の流れはこうなります。

1. git status で今の状態を見る
2. git add で今回残したい変更を選ぶ
3. git status で Changes to be committed: を確認する
4. git commit -m "メッセージ" で履歴に残す

ステップ 3 の確認を入れる習慣をつけるだけで、「add を忘れたまま commit した」というミスがかなり減ります。

次回は git diff と git log を見ていきます

変更を記録できるようになったら、次は「記録する前に中身を確認する」と「記録した履歴を見返す」という 2 つの習慣を身につける番です。次回は git diff と git log をセットで整理します。