本記事の構成および論理分析にはAI(人工知能)を使用しています。情報の正確性は、システム管理者(UNIXユーザー)による手動検証済みです。
第3回 | git add と git commit で変更を選んで記録する | 2ステップに分かれている理由をやさしく整理する | UNIX Cafe

Git 入門 | 第3回
Git で変更を記録するとき、なぜ git add と git commit の 2 ステップが必要なのでしょうか。最初は「まとめて 1 つでよいのでは」と感じる方も多いと思います。でもこの 2 つが分かれていることには、ちゃんと理由があります。
今回は git add と git commit をセットで整理します。それぞれの役割、実際の出力の読み方、よくあるつまずきポイントまで、順を追って見ていきます。
動画で流れを先に見たい方は、UNIX Cafe の YouTube もあわせてどうぞ。記事と同じく、初心者向けのやさしい流れで、ターミナルの最初の一歩を確認できます。
📝 この記事で学べること
git addとgit commitそれぞれの役割- なぜ 2 ステップに分かれているのか
- 実際のターミナル出力の読み方
- コミットメッセージの書き方と考え方
- 初心者がつまずきやすいポイントと対処
2 ステップの全体像をまず見ておく
最初に流れ全体を確認します。
| ステップ | コマンド | 何をするか |
|---|---|---|
| 1 | git add | 今回記録したい変更を選ぶ |
| 2 | git commit | 選んだ変更を履歴として残す |
add は「記録する」ではなく「記録の候補にのせる」操作です。commit して初めて、あとから見返せる履歴になります。
なぜ 2 ステップに分かれているのか
「add と commit をなぜ分けるのか」という疑問は、Git を学び始めたほぼ全員が感じるところです。理由は、変更を意味のある単位で整理して残すためです。
たとえば、ファイルに新しいメモを追記しながら、別のファイルの誤字も直したとします。この 2 つを 1 つのコミットにまとめると、あとで履歴を見たときに「この記録は何の変更だったのか」が分かりにくくなります。
add で先にメモの追記だけを選んで commit し、次に誤字の修正を選んで別の commit にする。こうすると、2 つの変更がそれぞれ独立した記録として残ります。小さく分けて残すほど、あとから何がどこで変わったかを追いやすくなります。
git add | 今回残したい変更を選ぶ
前回作った memo.txt に何か書き足して保存してみましょう。vi で編集する場合は次のようにします。
vi memo.txt- 開いたら i で入力モードに入り、テキストを追記します。
- 書き終えたら Esc を押して、
:wqと入力して保存・終了します。 - 保存できたら
git statusを実行するとmodified: memo.txtと表示されているはずです。
この変更を記録対象として選ぶのが git add です。
git add memo.txtこの時点ではまだ履歴には残っていません。「今回はこの変更を記録対象にしたい」と Git に伝えた段階です。
全ファイルをまとめて選びたい場合は、次のように書きます。
git add .末尾の . は「現在のフォルダにある変更をすべて選ぶ」という意味です。便利な反面、意図していないファイルまで一緒に選んでしまうことがあります。使う前に必ず git status で状態を確認する習慣をつけると安心です。
git add したあとの出力を読む
git add 自体は、成功しても何も表示されません。「何も出なかったけど大丈夫?」と不安になりやすいですが、これは正常な動作です。確認したいときは git status を使います。
git statusadd したあとに git status を実行すると、次のような表示になります。
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: memo.txt各行の意味はこうです。
| 表示 | 意味 |
|---|---|
On branch master | 今いるブランチ(今は気にしなくて大丈夫) |
Changes to be committed: | 次の commit に含まれる予定の変更 |
new file: memo.txt | このファイルが新規追加として add 済みの状態 |
Changes to be committed: の欄にファイルが表示されていれば、add は正しく通っています。new file: は今回が初めての記録、modified: は以前の記録から変更があった場合に表示されます。
git commit | 選んだ変更を履歴として残す
add で選んだ変更を、履歴として確定させるのが git commit です。-m のあとにクォートで囲んでメッセージを書きます。
git commit -m "はじめてのメモを追加"うまくいくと、次のような出力が表示されます。
[main (root-commit) a1b2c3d] はじめてのメモを追加
1 file changed, 1 insertion(+)
create mode 100644 memo.txt各行の意味はこうです。
| 表示 | 意味 |
|---|---|
[main (root-commit) a1b2c3d] | ブランチ名・初回コミットの印・コミット ID |
はじめてのメモを追加 | 自分が書いたコミットメッセージ |
1 file changed, 1 insertion(+) | 変更されたファイルの数と追加された行数 |
create mode 100644 memo.txt | 新しいファイルとして記録されたことを示す |
(root-commit) は「このリポジトリの最初のコミット」という意味です。2回目以降のコミットでは表示されません。a1b2c3d の部分は実際には異なる文字列になります。これはこの記録を識別するための ID で、コミット ID と呼びます。
ここで Git が行うのは、ファイルの上書きではありません。「この変更をいつ、どんな目的で加えたか」という記録を履歴に追加する操作です。
| 操作 | 何をするか |
|---|---|
| 保存(Ctrl+S など) | 今のファイルの内容を書き込む |
git commit | 何をいつ変えたかを履歴として積み重ねる |
コミットメッセージの書き方
コミットメッセージは、あとで履歴を見返したときに「この記録は何だったのか」を教えてくれる一言です。自分だけが使うローカル作業であっても、数週間後の自分が読んで分かる内容を書いておくと助かります。
良いメッセージと、そうでないメッセージの違いを見てみましょう。
| メッセージの例 | 評価 | 理由 |
|---|---|---|
memo.txt に作業ログを追記 | ◯ | 何をしたかが分かる |
設定ファイルのタイムゾーンを JST に変更 | ◯ | どこを何に変えたかが分かる |
修正 | △ | 何を修正したか分からない |
update | △ | 内容が何も分からない |
あとで直す | ✕ | あとで見ても意味をなさない |
日本語でも英語でも構いません。大切なのは、「何のための変更か」が一言で伝わることです。最初は短くても、具体的な内容を書く習慣をつけるだけで十分です。
初心者がつまずきやすいポイント
実際に操作してみると、いくつか「あれ?」となりやすい場面があります。あらかじめ知っておくと慌てずに済みます。
- 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 までの流れを確認する
実際の操作の流れはこうなります。
git statusで今の状態を見るgit addで今回残したい変更を選ぶgit statusでChanges to be committed:を確認するgit commit -m "メッセージ"で履歴に残す
ステップ 3 の確認を入れる習慣をつけるだけで、「add を忘れたまま commit した」というミスがかなり減ります。
次回は git diff と git log を見ていきます
変更を記録できるようになったら、次は「記録する前に中身を確認する」と「記録した履歴を見返す」という 2 つの習慣を身につける番です。次回は git diff と git log をセットで整理します。




