前回の続き――箱はできた、では変更はどう刻まれるか
前回のO-02では、ファイルと履歴をまとめて管理する単位であるリポジトリを学びました。履歴を入れる箱は用意できました。では、あなたが編集した変更は、どうやってその箱の履歴に刻まれるのでしょうか。実は、ファイルを直しただけでは履歴には残りません。変更が確定した履歴になるまでには、決まった3つの段階を通ります。この講義は、その通り道を1本の流れとして押さえる回です。
このスライドのポイント
- O-02: ファイルと履歴をまとめる単位＝リポジトリ（箱）を学んだ
- 箱は用意できた。では編集した変更は、どうやって履歴に刻まれるのか
- ファイルを直しただけでは履歴には残らない
- 確定した履歴になるまでには、決まった3段階を通る
3段階の定義――作業机・撮影台・保存点
3つの段階を、写真撮影にたとえて定義します。まずワーキングツリーとは、いまあなたが編集している最中のファイルたち、いわば作業机の上の状態です。次にステージとは、その中から次の保存に含める変更だけを選んで載せる場所で、撮影台にあたります。そしてコミットとは、撮影台に載せた内容を1つの履歴として確定すること、シャッターを切って保存点を作る操作です。コミットには、何をしたのかを表す説明文、メッセージを必ず付けます。作業机、撮影台、保存点。この3語がこの講義の中心です。
このスライドのポイント
- ワーキングツリー＝いま編集中のファイルたち（作業机）
- ステージ＝次の保存に含める変更を選んで載せる場所（撮影台）
- コミット＝ステージの内容を1つの履歴として確定すること（保存点）
- コミットには「何をしたか」を表す説明文（メッセージ）を付ける
なぜ必要か――保存点がないと「戻れない」
この3段階を知らないと、どの変更が保存済みで、どれがまだ未保存なのかが分からなくなります。すると、O-01で学んだ復元の力が使えません。戻りたくても、どの時点が保存点なのかが分からないからです。特にAIと組む開発では、大量のコードが一気に書き換わります。そこで効くのが、動いた瞬間にコミット、という習慣です。1つの機能が動いた瞬間を保存点にしておけば、次にAIが別の場所を壊しても、その保存点へ戻れます。
このスライドのポイント
- 3段階を知らないと、どの変更が保存済みか未保存かが分からない
- するとO-01で学んだ「復元」が使えない（戻りたい保存点が不明）
- AIとの開発では大量のコードが一気に書き換わる
- 効くのが「動いた瞬間にコミット」――動いた点を保存点にしておく
構造――作業机 → add → commit
構造は、左から右への一方通行の流れで捉えます。作業机で変更する、その中から選んだ変更をaddという操作で撮影台へ載せる、撮影台の内容をcommitという操作で履歴に確定する。この3段が基本の道です。ここで大切な原則が、小さく頻繁に、です。1つのコミットには、1つの意味のまとまった変更だけを入れます。あれもこれも詰め込んだ大きなコミットは、後から見ても何をしたのか読み取れず、戻したい部分だけ戻すこともできなくなります。
このスライドのポイント
- 左から右への一方通行: 作業机 →（add）→ 撮影台 →（commit）→ 履歴
- addで撮影台へ載せ、commitで履歴に確定する
- 原則は「小さく頻繁に」
- 1コミット＝1つの意味のまとまった変更
具体例――「動いたら1コミット」のリズム
具体的なリズムで見てみましょう。AIに機能を1つ追加させる、自分で動作を確認する、動いたら1コミットする。これを繰り返します。たとえば午後3時に、一覧表示が動いた、というコミットを残したとします。その後さらに手を加えて、夕方にアプリが壊れたとしても、午後3時の保存点へ戻れば、確実に動く状態からやり直せます。動いた瞬間にコミット、というリズムが、この安心を生み出します。
このスライドのポイント
- リズム: AIに機能を1つ追加 → 自分で動作確認 → 動いたら1コミット、を繰り返す
- 例: 午後3時に「一覧表示が動いた」というコミットを残す
- その後に手を加えて夕方に壊れても、午後3時の保存点へ戻れる
- 「動いた瞬間にコミット」が、この安心を生む
技術サンプルカード――保存の4コマンド
実際の操作を、4行のコマンドで見てみましょう。種別はコマンド、目的は変更を保存点にすることです。git statusは現状確認で、読み取り専用の安全なコマンドです。git add ドットで変更を撮影台へ載せ、git commit マイナスエムで説明文を付けて確定します。最後のgit log --onelineは履歴の確認で、これも安全です。読み方の要点は、addとcommitの2段で初めて保存されること、メッセージは何をしたかを日本語で書いてよいこと、の2つです。
このスライドのポイント
- 種別: command ／ 目的: 変更を1つの保存点にする
- サンプル本体:
混同しやすい概念――ファイル保存とコミット
混同しやすいのが、ファイルの保存とコミットです。B-03で見た、エディタでCmd+Sを押すファイル保存は、いま開いているファイルの中身を書き込むだけの操作です。これはワーキングツリー、つまり作業机の上が変わっただけで、履歴には一切残りません。履歴に残すには、addで撮影台へ載せ、commitで確定する必要があります。保存しただけでは戻れない、と覚えてください。
このスライドのポイント
- ファイル保存（B-03・エディタのCmd+S）＝いま開いた中身を書き込むだけ
- コミット＝履歴への確定
- 保存しただけでは、作業机が変わるのみで履歴には残らない
- 履歴に残すには add で撮影台へ、commit で確定が要る
バイブコーディングでの確認点――頼む前にコミット
バイブコーディングでの確認点は、たった1つです。AIに大きな変更を頼む前に、必ずコミットしてから頼む。これを習慣にします。A-09で学んだ高リスクな変更の前に、戻れる状態を自分の手で作っておく、という安全確保です。AIへの質問例としては、今の変更を、意味のまとまりごとに分けてコミットする案を出してください、メッセージも提案してください、と頼むとよいでしょう。区切り方まで相談できます。
このスライドのポイント
- 習慣化する1つのこと: AIに大きな変更を頼む前に、必ずコミットしてから頼む
- A-09の高リスクな変更の前に、戻れる状態を自分の手で作っておく安全確保
- AIへの質問例: 「今の変更を、意味のまとまりごとに分けてコミットする案を出してください。メッセージも提案してください」
まとめと次回――変更が履歴になる3段階
最後に一問一答です。変更が履歴になる3段階は何でしょうか。（間）答えは、ワーキングツリーで作業し、ステージで含める変更を選び、コミットで確定する、の3段階です。30秒まとめです。作業机、撮影台、保存点。そして、動いた瞬間にコミットするリズムが、あなたの安全網になります。次回のO-04では、A-04以来ずっと言い続けてきた差分確認を、実際に行うための正式な道具として学びます。関連資料は、Git・GitHub 完全入門と、AI開発日報テンプレートです。
このスライドのポイント
- 一問一答: 変更が履歴になる3段階は?
- 答: ワーキングツリー（作業）→ ステージ（選択）→ コミット（確定）
- 30秒まとめ: 作業机・撮影台・保存点。「動いた瞬間にコミット」が安全網
- 次回O-04: A-04以来の「差分確認」を実行する正式な道具へ
- 関連資料: 「Git・GitHub 完全入門」「AI開発日報テンプレート」
