章: 第1章: Gitの土台を作る
「addしてcommitする」の意味を曖昧にしない
Gitを触り始めると、git add と git commit をセットで覚えることが多いです。しかし、ただ流れで打っているだけだと、あとで履歴が読みにくくなります。
git add はコミット対象を選ぶ操作、git commit は選んだ変更を履歴として記録する操作です。
この2つは役割が違います。ここを分けて理解することが、きれいな履歴を作る第一歩です。
git add は「ステージに載せる」操作
git add index.php
このコマンドを実行しても、まだ履歴は作られません。変更を「次のコミット候補」に載せただけです。
つまり add は、変更の中から今回は何をコミットするかを選ぶ工程です。
複数ファイルを触っていても、関係ある変更だけをまとめる意識が大事です。
git commit で履歴を作る
git commit -m "fix: ログイン時のバリデーションを修正"
ここで初めて履歴が1件作られます。コミットメッセージは「その変更で何をしたか」を短く明確に書きます。
良いコミットは、あとから見返したときに意味がわかります。
悪い例:
updatefixいろいろ変更
良い例:
fix: ログイン時のメール形式チェックを修正feat: 記事一覧にページネーションを追加
なぜ分ける必要があるのか
たとえば次のような変更が同時にあるとします。
- ログインバグ修正
- 不要な空白の整形
- README更新
これを全部まとめて1コミットにすると、あとで履歴を読む人が困ります。
「バグ修正だけ戻したい」のに、README変更までくっついていると扱いづらいからです。
コミットは“作業単位”ではなく“意味の単位”で分けるのが基本です。
実務で意識したいこと
| 操作 | 意識すること |
git add |
今回コミットしたい変更だけを選ぶ |
git commit |
後から見ても意味がわかる1件にする |
この感覚が身につくと、レビューも差し戻しもやりやすくなります。実務では「コードを書く力」と同じくらい、「履歴を読みやすく保つ力」が評価されます。
チェックポイント:
addは選別、commitは記録。この順番で意味を理解しておきましょう。
まとめ & 次のステップ
git addはコミット対象を選ぶ操作git commitは選んだ変更を履歴に記録する操作- コミットは意味の単位で分けると読みやすい
- コミットメッセージは具体的に書く
- 履歴の質は将来の作業効率に直結する
次回は git log と git show を扱います。 作った履歴をどう読み返すかがわかると、Gitの便利さをさらに実感できます。
