なぜAI時代こそGit/PR運用なのか

学習のねらい

AIにコードを書いてもらうと、何十行もの変更が一度に作られることがあります。 変更を小分けに記録しておかないと、後で「どこを戻せばよいか」が分からなくなりがちです。 ここで役立つのが Git と Pull Request(PR、変更内容を確認するためのGitHubの仕組み)です。 本レッスンでは、その役割と最小限のルールを身につけましょう。

押さえたい3つのポイント

1. AIは大きな変更を一気に作る AIは1回の指示で数ファイル・数十行を書き換えることがあります。 変更ごとに ブランチ(作業用の枝)を分け、PRで内容を確認できる単位にしておくと、後から見返したり戻したりしやすくなります。

2. PRは「人が確認する場」 PRはGitHub上で変更内容を表示し、コメントを残せるしくみです。 AIが書いたコードでも、自分が一度読んでから取り込む(merge する)ことで、理解できないコードがそのまま入ることを防げます。 自分のPRに自分でコメントを残す習慣にすると、後で読み返したときに役立ちます。

3. 記録の責任は保存した人にある Gitの履歴には「いつ・誰が・どの変更を保存したか」が残ります。 AIに書いてもらったコードでも、保存した人(つまり自分)が責任を持つ前提です。 だからこそ、内容を理解できないコードはそのまま取り込まないようにしましょう。

本コースで使うブランチ名

• feat/<scope>-<short-desc> — 新しい機能を追加するとき
• fix/<scope>-<short-desc> — バグを直すとき
• exp/<scope>-<short-desc> — 試しに作ってみるとき(まだmergeしないもの)

よくあるつまずき

AIに書いてもらったコードを、確認せずに main ブランチへそのまま push してしまうケースです。 ブランチ → PR → 自分での確認 → merge の順を守るだけで、後から「いつ何が変わったか」を辿りやすくなります。 個人開発でも同じで、3ヶ月後の自分が読み返すときに助かります。

まとめ

Git/PRは「速度を落とすため」ではなく、「速度を出しても安心できるようにするため」のしくみです。 AIで生産性が上がるほど、この習慣が後の自分を助けてくれます。