他の人が先にマージした場合の対応方法【詳細解説】

以下では、「他の人が先にブランチをマージし、main が更新された」 場合に、自分の作業ブランチへその変更を取り込むときの対応を詳しく解説します。
このステップを正しく理解しておくと、コンフリクトを早めに解消できたり、開発中のブランチが古いコードに依存してしまうリスクを減らせます。

背景シナリオ

  • Member A が feature/exit-button を main にマージ済み。
  • Member B は同時期に feature/reset-button ブランチで作業しており、まだマージしていない状態。
  • すると、B のブランチは 「Exit ボタンがない時点」の main から分岐しているため、メインの最新変更を取り込んでいない。
  • B がこのままプルリクエストを送ると、コンフリクト やテスト時の不具合が出る可能性がある。
  • そこで、B が作業中のブランチに最新の main を取り込んで追従させることが必要になる場合があります。

1. マージ前のブランチに最新 main を取り込む必要があるかどうか

すぐに取り込みたいケース

  1. 他の人が先に大きな変更を行ったり、同じファイルを編集している場合
  2. 自分のブランチの作業で、その新しい変更を使いたい／前提としたい場合
  3. コンフリクトが起きる可能性が高く、早めに解消しておきたい 場合

後で取り込んでもいいケース

  1. 作業内容が main とほとんどかぶらず、コンフリクトの可能性が低い場合
  2. 機能的な依存が少ない場合
  3. ブランチの生存期間が短く、すぐにプルリク＆マージできそうな場合

いずれにしても、ブランチを長期間最新化しないまま放置すると、あとから大きなコンフリクトを引き起こすリスクが高まるので注意しましょう。

2. 実際の操作手順（GitHub Desktop での例）

2-1. ローカル main を最新化

  1. GitHub Desktop を開き、ブランチを main に切り替える。
  2. 上部にある「Fetch origin」→「Pull origin」ボタンをクリックし、リモート上の main をローカルに同期。
  • これで、他のメンバーが先にマージした変更が ローカルの main に取り込まれた状態になります。

2-2. 作業中のブランチに切り替え、main を取り込む

  1. GitHub Desktop 上部の「Current branch」メニューから、自分の作業ブランチ（例：feature/reset-button）を選択。
  2. メニューバーの「Branch」→「Merge into current branch…」(または「Update from main」) を選択。
  3. ダイアログで「main」を指定し、「Merge main into feature/reset-button」を実行。
  • これにより、ローカルの最新 main の変更が自分のブランチに取り込まれます。

2-3. コンフリクトがあれば解消

  • 同じファイルの同じ行を複数のブランチが変更している場合など、競合（コンフリクト）が発生することがあります。
  • GitHub Desktop で競合したファイルは赤字表示になります。
  • Visual Studio や外部ツールで内容を比較しつつ、必要な行を残す・不要な行を削除するなど、手動で正しい内容にまとめます。
  <<<<<<< HEAD
      // 自分のブランチの変更
      count = 0;
  =======
      // 他ブランチの変更
      this.Close();
  >>>>>>> main

上記の例であれば、両方必要ならファイル上で正しく統合して保存し直します。

  • 競合解消後、GitHub Desktop の「Changes」タブで解消済みファイルを確認 → 下部でコミットメッセージを入力 → 「Commit merge」 をクリック。

2-4. プッシュ & 続行

  • 競合解消コミットが完了したら、「Push origin」でリモートブランチに更新を反映します。
  • これで、最新 main を取り込んだ状態で引き続き開発を続けられます。

3. プルリクエストが既に作成されている場合

  • 自分のブランチで プルリクを既に出している ときに、他の人が先に別のブランチをマージして main が更新されるケースもあります。
  • 上記と同様に ローカルでコンフリクト解消 → プッシュ すれば、開いているプルリクエストにも最新が反映され、コンフリクトが解消された状態になります。
  • GitHub の Web UI 上で直接コンフリクトを解決することも可能ですが、複雑なファイルの競合はローカルでじっくり作業したほうがやりやすい場合が多いです。

4. マージ後のブランチはどうするか

  • マージ後のブランチ は、プルリクエストが完了して main に取り込まれたら、不要なので削除します。
  • 新たな作業が必要なら、最新 main から新しいブランチを作る方が履歴がスッキリします。
  • 「最新化作業」は、あくまで マージ前 のブランチで作業継続中に main を取り込む行為です。プルリク完了後のブランチは基本的に使い続けません。

5. まとめとポイント

  1. 他の人が先にマージしたら、main が更新される
    • 放置すると、あとからコンフリクトが大きくなる可能性がある。
  2. ローカル main を Pull → 自分のブランチに「Merge main into …」で取り込む
    • 必要に応じてコンフリクト解消 → コミット & プッシュ。
  3. コンフリクト解消は早めが吉
    • 放置していると変更範囲が大きくなり、手間が増える。
  4. マージ後のブランチは削除
    • 役目を終えたらブランチをクリーンにし、次の機能は改めて新ブランチを切る。

おわりに

他の人の変更が先にマージされる状況は、チーム開発ではよくあります。
ポイントは「自分の作業が古いベースで進んでいないかを常に意識し、必要に応じて最新化すること」 です。
コンフリクトが発生した際も、落ち着いて手順どおりに解消すれば大丈夫。何度か経験すれば慣れてきます。

こうしたブランチの更新や競合解消をマスターして、スムーズなチーム開発を実現しましょう。

バージョン管理,便利機能

Posted by hidepon