前回の続き——分けたものを、安全に1つへ戻す
前回のO-05では、本線を守りながら支線で安全に試すブランチを学びました。支線で育てた変更は、いつか本線へ戻して1つにまとめる必要があります。その合流の操作が、これから学ぶマージです。そして合流のとき、ときどき起きるのがコンフリクトです。この講義は、分けたものを安全に統合するための回にあたります。
このスライドのポイント
- O-05: 本線（main）を守り、支線（機能ブランチ）で安全に試すのがブランチだった
- 支線で育てた変更は、いつか本線へ戻して1つにまとめる必要がある
- その合流の操作が「マージ」
- 合流のとき、ときどき起きるのが「コンフリクト」
マージとコンフリクトの定義
まず正式に定義します。マージとは、あるブランチの変更を別のブランチへ統合することです。多くの場合、支線の変更を本線へ取り込む向きで行います。コンフリクトとは、2つの系列が同じ箇所をそれぞれ別々に変更していて、機械にはどちらが正しいかを決められない状態を指します。ここが最も大切な点です。コンフリクトはGitが壊れたのではなく、人間の判断待ちの合図です。このときファイルの中には両方の版が並べて記され、人が選んで確定します。
このスライドのポイント
- マージ＝あるブランチの変更を、別のブランチへ統合すること（多くは支線→本線）
- コンフリクト＝2つの系列が同じ箇所を別々に変更し、機械には正解を決められない状態
- 最重要: コンフリクトはGitが壊れたのではなく、「人間の判断待ち」の合図
- このときファイル内に両方の版が並記され、人が選んで確定する
なぜ知る必要があるか——記号を見て慌てないために
なぜこれを知る必要があるのでしょうか。コンフリクトが起きると、ファイルの中に見慣れない記号が現れます。これを見て壊れたと思い込み、慌てて全部消してしまう二次事故が、初心者に最も多く起きます。実際にやることは、落ち着いてどちらの変更を残すかを選ぶだけです。正体を知っているかどうかで、対応がまるで変わります。
このスライドのポイント
- コンフリクトが起きると、ファイル内に見慣れない記号（<<<< など）が現れる
- 知らないと: 壊れたと思い込み、慌てて全部消してしまう二次事故が最も多い
- 実際にやることは、落ち着いてどちらの変更を残すかを選ぶだけ
- 正体を知っているかどうかで、対応がまるで変わる
コンフリクトが起きる条件と、3つの解消法
コンフリクトが起きる条件は決まっています。2つのブランチが、同じファイルの同じ行を別々に変更したときです。逆に、違うファイルや離れた場所への変更なら、機械が自動でまとめてくれます。解消のしかたは3択です。片方の版を残す、両方を活かして書き直す、あるいはまったく新しく書き直す。この3つのどれかを人間が選んで、合流を確定させます。
このスライドのポイント
- 発生条件: 2つのブランチが、同じファイルの同じ行を別々に変更したとき
- 違うファイルや離れた場所への変更なら、機械が自動でまとめてくれる
- 解消は3択: ①片方の版を残す ②両方を活かして書き直す ③新しく書き直す
- どれかを人間が選び、合流を確定させる
具体例——同じ関数に両方が触れたとき
具体例で見ましょう。支線では承認機能を追加し、本線ではバグ修正をしていて、たまたま同じファイルの同じ関数に触れていたとします。この状態でマージすると、機械はどちらを残せばよいか決められず、コンフリクトになります。ここで有効なのが、AIに両方の変更意図を説明させ、両立させる統合案を作らせることです。その案を人間が確認し、意図どおりなら確定します。判断そのものは人間が持ち続けます。
このスライドのポイント
- 支線: 承認機能を追加／本線: バグ修正。たまたま同じファイルの同じ関数に触れていた
- マージすると、機械はどちらを残すか決められず、コンフリクトになる
- 有効な打ち手: AIに両方の変更意図を説明させ、両立させる統合案を作らせる
- その案を人間が確認し、意図どおりなら確定する（判断は人間が持ち続ける）
技術サンプル——コンフリクト表示の読み方
実際の表示を読んでみます。目印は3つの記号です。<<<<<<< から ======= までが一方の版、======= から >>>>>>> までがもう一方の版です。つまり記号は、ここからここまでが版A、ここからが版Bという仕切りにすぎません。解消するときは、残す内容を決めたうえで、この3つの記号の行ごと消します。記号を消し忘れると、そのままでは正しく動きません。AIに頼むときは、両方の変更意図を説明したうえで統合案を出してもらうと安全です。
混同しやすい点——「判断待ち」と「壊れた」
混同しやすいのは、コンフリクトと壊れたことの区別です。繰り返しになりますが、コンフリクトは判断待ちであり、正常な仕組みの一部です。壊れた異常ではありません。ただし、もしコンフリクトが頻繁に起きるなら、それは別のサインです。同じファイルを複数の作業で同時に触る計画になっていないかを見直す合図として受け取ってください。
バイブコーディングでの確認点
バイブコーディングでの確認点です。コンフリクトの解消は、AIに任せることもできます。しかし機械的に混ぜた結果が、そのまま正しく動く保証はありません。ですから解消した後は、必ず自分で動作を確認してからコミットします。A-04で学んだとおり、最終確認は人間の仕事です。AIへの質問例は、このコンフリクトの両方の変更意図を説明し、両立させる統合案を出してください、です。
このスライドのポイント
- コンフリクトの解消はAIに任せることもできる
- ただし機械的に混ぜた結果が、そのまま正しく動く保証はない
- 解消後は必ず自分で動作を確認してからコミットする
- A-04のとおり、最終確認は人間の仕事
- AIへの質問例:「このコンフリクトの両方の変更意図を説明し、両立させる統合案を出してください」
まとめと次回
最後に一問一答です。コンフリクトはエラーでしょうか、それとも判断待ちでしょうか。……答えは、判断待ちです。機械が決められない重なりを、人が選んで確定します。30秒でまとめます。マージは変更の合流、コンフリクトはその合流での判断待ち、対処は残す内容を選ぶだけ、そして解消後は必ず動作確認、です。次回O-07では、手元の履歴を別の場所と共有する仕組みへ進みます。関連資料は、Git・GitHub 完全入門と、エラー文の読み方です。
このスライドのポイント
- 一問一答:「コンフリクトはエラーか、判断待ちか？」→ 判断待ち（機械が決められない重なりを人が選ぶ）
- 30秒まとめ: マージ＝変更の合流／コンフリクト＝合流での判断待ち／対処＝残す内容を選ぶ／解消後は必ず動作確認
- 次回O-07: 手元の履歴を別の場所と共有する仕組みへ
- 関連資料: 「Git・GitHub 完全入門」「エラー文の読み方」
