マージとは？
マージは、あるブランチで進めた変更を別のブランチへ統合する操作です。たとえばfeature/searchで完成した検索機能をmainへ取り込みます。
Gitは、ブランチが分かれたあとにそれぞれで行われた変更を調べ、両方をまとめようとします。GitHubでは、プルリクエストの確認後にMergeボタンで統合する流れがよく使われます。
プルとの違い
マージはブランチ同士の履歴を統合する仕組みです。プルはリモートの変更を取得し、現在のブランチへ統合する一連の操作です。標準的な設定では、プルの途中でマージが使われることがあります。
マージコンフリクトとは？
二つのブランチで同じ行が違う内容へ変更されていると、Gitはどちらを採用すべきか自動判断できません。この状態をマージコンフリクト、または競合と呼びます。
コンフリクトは故障ではなく、人の判断が必要という案内です。両方の変更理由を確認し、残す内容を編集してからコミットします。
マージ前に確認すること
- 取り込む向きが正しいか
- テストや表示確認が終わっているか
- 不要なファイルや秘密情報が含まれていないか
- プルリクエストの指摘が解決しているか
マージ後に自動デプロイが動くプロジェクトもあります。mainへ入れる操作が公開へどうつながるかも確認しましょう。
マージ結果の残り方
履歴の位置関係によっては、ブランチの参照先を前へ進めるだけのFast-forwardになる場合があります。また、二つの流れを統合したことを示すマージコミットが作られる場合もあります。
GitHubのプルリクエストでは、複数コミットをそのままマージする方法のほか、一つにまとめるSquash merge、履歴を並べ直すRebase mergeなどを選べることがあります。どれが正しいかはプロジェクトの運用方針によります。初心者は勝手に方式を変えず、既存のルールに合わせるのが安全です。