章: 第3章: 実務で詰まりやすい分岐と共有
ブランチを分けたら、最後は戻す必要がある
ブランチは作業を分けるための仕組みですが、分けたままだと本流には反映されません。
そこで使うのが merge です。
merge は、別ブランチの変更を現在のブランチへ取り込む操作です。
基本的な流れ
たとえば main に作業結果を戻すなら、次のような流れになります。
git switch main
git merge feature/login-validation
これで、作業ブランチの内容が main に取り込まれます。
変更箇所が重なっていなければ、そのままスムーズに終わることが多いです。
コンフリクトは「Gitが自動で決められない状態」
問題になるのは、同じ行付近を別ブランチでそれぞれ変更していた場合です。
このときGitは、どちらを採用すべきか自動判断できず、コンフリクト になります。
コンフリクトは失敗ではありません。むしろ「人間の判断が必要」と正直に止まってくれている状態です。
まずやること
コンフリクトしたら慌ててコマンドを打つより、まず対象ファイルを開いて内容を確認します。
典型的には次のような印が入ります。
<<<<<<< HEAD
現在ブランチの内容
=======
取り込み側ブランチの内容
>>>>>>> feature/login-validation
この印を見ながら、どちらを残すか、あるいは両方を統合するかを決めます。
実務で大切な姿勢
コンフリクト解消で大事なのは、機械的に片方を選ばないことです。
- どちらが新しい意図なのか
- 片方だけ残して問題ないか
- 両方の修正を統合すべきか
を見て判断する必要があります。
チェックポイント: コンフリクトは「壊れた」ではなく「判断待ち」です。まず落ち着いて差分を読みましょう。
まとめ & 次のステップ
mergeは別ブランチの変更を現在ブランチに取り込む操作- 同じ箇所の変更が重なるとコンフリクトが起きる
- コンフリクトはGitが自動判断できない状態
- 解消時は片方を機械的に選ばず意図を読む
- まずは流れを理解することが重要
次回は push と pull を扱います。 ローカルで作った履歴をリモートとどうやり取りするかを最後に整理します。
