前回の続き——差分を読めたら、次は試す場所を分ける
前回のO-04では、AIが何を変更したかを差分で正確に読む方法を学びました。差分で変更を確認できても、その変更をいきなり本線の上で行えば、実験が失敗した瞬間に、動くバージョンが消えてしまいます。この講義の役割は、変更を試す場所そのものを本線から切り離すことです。バージョン管理の3能力のうち、O-01で名前だけ挙げた分岐が、いよいよ実体を持ちます。
このスライドのポイント
- O-04で学んだこと: AIが何を変更したかを差分で正確に読む
- 課題: 差分を読めても、本線の上で直接試せば失敗した瞬間に動くバージョンが消える
- この講義の役割: 変更を試す「場所」そのものを本線から切り離す
- O-01で名前だけ挙げた3能力の「分岐」が、ここで実体を持つ
ブランチとは何か
ブランチとは、履歴が分岐した一本の変更系列のことです。開発の中心となる本線をmainと呼び、mainは常に動く状態に保ちます。新しい機能を作るときは、mainから枝分かれさせた支線、つまり機能ブランチの上で変更を行い、完成してから本線へ合流させます。この合流の操作は、次回学ぶマージです。O-01でバージョン管理の3能力として挙げた比較・復元・分岐のうち、分岐の正体が、このブランチです。
このスライドのポイント
- ブランチ＝履歴が分岐した1本の変更系列
- 本線をmainと呼び、mainは常に動く状態を保つ
- 変更は支線（機能ブランチ）で行い、完成後に本線へ合流させる（合流＝次回のマージ）
- O-01の3能力（比較・復元・分岐）のうち「分岐」の実体がブランチ
なぜ必要か——本線の上で直接試す危うさ
ブランチを使わないと、どうなるでしょうか。作りかけの機能を本線の上で直接いじることになり、途中で手が止まれば、動くバージョンが一つも存在しない状態が生まれます。さらに、新機能の追加と別の不具合の修正を同じ本線で同時に進めると、二つの変更が混ざり合い、どちらが原因でどこが壊れたのかを切り分けられなくなります。ブランチは、この二つの事故を、作業の場所を分けることで未然に防ぎます。
このスライドのポイント
- 本線で直接実験すると「動くバージョンが一つも存在しない」状態が生まれる
- 機能追加と不具合の修正を同じ本線で同時に進めると、変更が混ざる
- 混ざると「どちらが原因でどこが壊れたか」を切り分けられなくなる
- ブランチは、作業の場所を分けることでこの2つの事故を未然に防ぐ
構造——本線と支線の線路図
構造を線路の図で見てみましょう。中央を走る一本の線がmainで、ここは常に動く状態が守られます。ある時点でmainから支線が枝分かれし、その支線の上で変更をいくつか積み重ねます。実験がうまくいけば、支線は本線へ合流します。大切なのは、支線で何をしていても、合流するまで本線には一切影響しないという点です。だからmainは常に動く、という原則が保てます。
このスライドのポイント
- 中央を走る一本の線がmain、ここは常に動く状態が守られる
- ある時点でmainから支線が枝分かれし、支線の上で変更を数回積み重ねる
- 実験がうまくいけば、支線は本線へ合流する
- 支線で何をしても、合流するまで本線には一切影響しない
具体例——承認機能を支線で試す
具体例で考えます。経費アプリに承認機能を試したいとします。まず承認機能用のブランチを切り、その支線の上でAIと一緒に実装を試します。うまくいけば本線へ合流させ、もし方針がだめだと分かったら、支線ごとまるごと捨てます。このとき本線は最初から一度も触れられていないので、無傷のまま残ります。A-09で学んだ元に戻せる変更を、一つの変更ではなく、実験まるごとの単位で実現できる道具が、ブランチです。
このスライドのポイント
- 経費アプリに承認機能を試したい
- 承認機能用のブランチを切り、支線の上でAIと実装を試す
- うまくいけば本線へ合流、だめなら支線ごとまるごと捨てる
- 本線は一度も触れられていないので無傷のまま残る
- A-09の「元に戻せる変更」を、実験まるごとの単位で実現する道具
技術サンプル——ブランチを扱う3コマンド
技術サンプルは、ブランチを扱う三つのコマンドです。git branchで現在のブランチ一覧を確認でき、これは読み取り専用の安全なコマンドです。git switch -c feature-approvalは、feature-approvalという名前のブランチを新しく作り、同時にそこへ移動します。作業を終えて本線へ戻るときは、git switch mainです。ここで大切な読み方は、ブランチを切り替えても、他のブランチの内容は消えていない、ということです。見えなくなるだけで、別の場所にきちんと保存されています。
混同しやすい——「消えた」ように見えて、消えていない
初心者が最も驚く場面を、先回りしておきます。ブランチを切り替えると、さっきまで見えていたファイルが消えたように見えることがあります。これを、変更が失われたと勘違いしがちです。しかし実際には、それらのファイルは別のブランチにそのまま保存されており、元のブランチへ切り替えれば、また現れます。つまり、切替でファイルが消えたように見えるだけで、実際は別ブランチに保存されている、と覚えてください。
このスライドのポイント
- ブランチを切り替えると、さっきまで見えていたファイルが消えたように見えることがある
- これを「変更が失われた」と勘違いしがち
- 実際には、それらは別のブランチにそのまま保存されている
- 元のブランチへ切り替えれば、また現れる
バイブコーディングでの確認点
バイブコーディングでの確認点です。AIに実験的な変更や大きな機能追加を頼むときは、ブランチを切ってから始める、を定型にしてください。mainへ直接加える変更は、文言の修正のような小さく安全なものに限ります。AIへは、この作業用のブランチを切ってから始めてください、ブランチ名も提案してください、と最初に伝えるとよいでしょう。作業の場所を先に分けておくことが、失敗しても本線を守る一番の保険になります。
このスライドのポイント
- AIに実験的な変更や大きな機能追加を頼むときは「ブランチを切ってから」を定型に
- mainへ直接加える変更は、文言の修正のような小さく安全なものに限る
- 質問例: 「この作業用のブランチを切ってから始めてください。ブランチ名も提案してください」
- 場所を先に分けておくことが、失敗しても本線を守る保険になる
まとめと次回
最後に一問一答です。実験がうまくいかなかったとき、ブランチ運用なら何を捨てればよいでしょうか。……答えは、支線、つまりブランチごと捨てる、です。本線は無傷のまま残ります。三十秒のまとめです。ブランチは履歴を分岐させた変更系列で、本線を守りながら支線で安全に試すための仕組みでした。次回のO-06では、この支線を本線へ合流させるマージと、そこで起きるコンフリクトを学びます。関連資料は、Git・GitHub 完全入門と、Git・GitHubワード50です。
このスライドのポイント
- 一問一答: 実験がだめだったとき、ブランチ運用なら何を捨てる？ → 支線（ブランチ）ごと捨てる（本線は無傷）
- 30秒まとめ: ブランチは履歴を分岐させた変更系列。本線を守りながら支線で安全に試す仕組み
- 次回O-06: 支線を本線へ合流させる「マージ」と、そこで起きる「コンフリクト」へ
- 関連資料: 「Git・GitHub 完全入門」「Git・GitHubワード50」
