Lecture 15Gitの基本とバージョン管理

commit は ゲームのセーブポイント です。 「ここまで進めた状態」を1つのまとまりとして記録します。 後から「あのセーブまで戻りたい」と思ったときに、ここに戻れます。

commitには 必ずメッセージ をつけます。 「何を変えたか」「なぜ変えたか」を1〜2行で残しておく。 これは 未来の自分への手紙 です。3か月後の自分が読んだとき、判断できる文章になっていれば合格です。

• 悪い例：fix、update（何をしたか分からない）
• 良い例：サイドバーのレクチャー番号がズレるバグを修正
• Codexはメッセージも書いてくれます。一緒に内容を確認するクセをつけます。

branch（ブランチ）は、本線とは別の作業ライン を作る仕組みです。 ゲームで言うなら、本編のセーブデータを汚さずに「別ファイルで実験プレイをする」ようなものです。

AI開発では特に効きます。 AIに大きな変更を任せるとき、本線（main）から枝分かれしたbranchで作業すれば、 うまくいかなくても 本線は無傷のまま。実験的な依頼を出しやすくなります。

• 本線（main）：いつでも公開できる、安定した状態。
• 作業branch（例：feature/sidebar）：新機能を試す場所。完成したら本線に合流（マージ）させる。
• 失敗したらbranchごと捨ててOK。本線には傷がつかない。

diff（ディフ）は 変更前と変更後の差 を見せてくれる機能です。 赤字＝消えた行、緑字＝追加された行、と色分けされています。

AIに何かを任せた直後は、必ずdiffを見てください。非エンジニアこそ、diffを見るクセが守りになる からです。 関係ないファイルが変わっていないか、消えてはいけない行が消えていないか、を一目でチェックできます。

ハンズオンでは、GitとGitHubを次の流れで使います。 最初はコマンドを覚える必要はありません。いま自分がどの段階にいるかを説明できればOKです。

1. Clone：GitHubのリポジトリを自分のPCへ持ってくる。
2. Branchを作る：main から分かれた作業場所を作る。
3. 変更する：Codexに実装や修正を依頼する。
4. Diffを見る：何が変わったかを確認する。
5. Commitする：問題ない変更をセーブポイントとして保存する。
6. Pushする：自分のPCにあるcommitをGitHubへ送る。
7. Pull Requestを作る：mainへ入れてよいか、チームで確認する。

AIは速く、たくさん変更します。だからこそ 巻き戻せる安心感 がないと、 大胆な依頼ができません。Gitは、その安心感そのものです。

• commitしてから依頼する：直前の状態に戻れるようにしておく。
• 大きな変更はbranchで：失敗したらbranchを捨てれば終わり。
• 依頼直後はdiffを見る：関係ない変更が混ざっていないかチェック。

• commit はセーブポイント、メッセージは未来の自分への手紙だと理解している。
• branch は本線を汚さない作業ラインだと説明できる。
• diff は変更前後の差分で、AIの変更後に必ず見るクセがついている。
• Clone、branch、diff、commit、push、Pull Requestの順番を大まかに説明できる。