GitHubにおけるコンフリクトとは、複数の変更が衝突し、Gitがどちらを信頼すべきか判断できない、厄介な瞬間のことです。コンフリクトが解決されないまま放置されると、ブランチのマージは実行されなくなり、特に締め切りが迫っている場合は非常に厄介です。このクイックガイドでは、ターミナル、Webインターフェース、お気に入りのIDEなど、どのツールを使っていても、コンフリクトを適切に解決する方法を解説します。コンフリクトへの対処方法を理解することで、多くの頭痛の種を回避し、状況が複雑になってもコードのマージを迅速化できます。
GitHubで競合を解決する方法
方法 1: ターミナル (コマンドライン) を使用する
これは最も徹底的な方法で、マージ対象を完全に制御できます。複雑なコンフリクトがある場合や、残すものを慎重に選びたい場合に最適です。なぜこれが役立つのでしょうか?それは、実際に確認、編集し、何が何であるかを決定できるからです。コンフリクトが発生した場合、マージ中にコードにフラグが付けられるので、この方法が役立ちます。最終的には、プッシュできるクリーンでコンフリクトのないブランチが完成するはずです。
- まず、実行します
git fetch origin
。これにより、GitHub 上の変更内容がローカルコピーに反映されますが、現在の変更内容は影響を受けません。ローカルブランチが遅れていると、競合が発生することがあります。 - 機能ブランチまたは作業ブランチに切り替えます:
git checkout branch-name
。 をbranch-name
実際のブランチ名に置き換えてください。不明な場合は、git branch
アクティブなブランチ名を入力して確認してください。 - 次に、ターゲットブランチ(通常は
main
または)の最新の変更を (または任意のブランチ)develop
にマージしますgit merge main
。この際、競合が存在する場合は警告が出ます。 - Gitが競合をフラグ付けした場合は、競合しているファイルを開いてください。<<<<<<<、=======、>>>>>>>といったマーカーが表示されます。面倒ですが、これを解決する唯一の方法です。
- どのコードを保持するかを決めます。現在の変更を保持するか、これから変更するコードを保持するか、それともそれらを結合するかです。編集後は競合マーカーを削除します。少し奇妙に思えますが、ここは本当に注意が必要です。
- ファイルを保存し、 でステージングします
git add filename
。競合するすべてのファイルに対してこれを繰り返します。 - すべての競合が解決されステージングされたら、 でコミットします
git commit
。Git によってメッセージが自動的に入力される場合もありますが、意味が通っているかどうか再度確認してください。 - 最後に、 を使用してブランチを GitHub にプッシュします
git push origin branch-name
。これで完了です。
この方法は、競合が発生している場所を正確に把握し、それぞれの解決方法を判断できるため、非常に便利です。設定によっては、競合が最初は解決しにくい場合があり、git fetch
再度実行したり、ターミナルを再起動したりする必要があるかもしれません。
方法2: GitHub WebまたはIDE経由で競合を修正する
コマンドラインが苦手な場合や、競合が軽微な場合は、これが手軽で簡単な方法です。GitHubでプルリクエストを開き、「競合を解決」をクリックするだけで、組み込みのエディターが起動して問題を解決できます。VS CodeなどのIDEを使用している場合は、競合がエディター内で直接ハイライト表示され、新しい変更を受け入れるか、現在の変更を受け入れるかを選択するボタンが表示されます。通常、これは単純で小さな競合の場合に最適な方法ですが、ターミナルでしか確認できない深刻な問題やコンテキストを見逃してしまう可能性があるので注意してください。
- GitHub のプル リクエスト ページに移動します。
- 「競合を解決」ボタンをクリックします。これは通常、GitHub が PR レビュー中に競合を検出したときに表示されます。
- 表示されるエディタを使用して、保存する変更を選択するか、必要に応じて手動で編集してください。変更を保存してください。
- すべての競合が解決したら、GitHub で直接マージをコミットします。
- VS Code で作業している場合は、競合が発生しているファイルを開きます。ファイルには <<<<<<<、=======、>>>>>>> のマークが付いています。競合の上にあるオプションから、 「現在の変更を受け入れる」や「新しい変更を受け入れる」などのオプションを選択できます。これらのファイルを保存してステージングしてください。
これは、競合が単純な場合や、ツールを切り替えずにすぐに修正が必要な場合に便利です。CLIで問題が発生するのが心配な場合は、こちらも試してみてください。
将来の紛争を回避するためのヒント
- ローカルブランチを最新の状態に保つために、メインブランチまたはメインブランチから頻繁にプルしてください。なぜでしょうか?ブランチがチェックされていない状態が長く続くと、マージ時に競合が発生する可能性が高くなるためです。
- 同じファイルで作業している場合は、チームメイトとチャットしてください。お互いを驚かせるよりも、調整する方がよいでしょう。
- 機能ブランチは短命にしておきましょう。長く放置すればするほど、ブランチ間の相違が大きくなり、マージバック時に大きな衝突が発生する可能性があります。
- プル リクエストとコード レビューを使用して、重複する作業を早期に発見し、競合が後で大きな問題になることを防ぎます。
なぜ紛争は起こるのか?
- 2 つのブランチが同じコード行またはセクションを変更すると、Git はどの変更を保持するか混乱してしまいます。
- あるブランチではファイルが削除され、別のブランチでは編集されるため、重複の競合が発生します。
- ブランチは時間の経過とともにさまざまな編集によって分岐するため、マージすると競合が発生します。
つまり、これらの競合を手動で確認し、適切なコードを選択する必要があり、これは面倒なこともありますが、避けられないことです。
よくある質問
マージ競合エラーは、ターミナルに表示されるか、GitHub がプルリクエスト処理中にフラグを立てた場合に表示されます。通常、Git は競合について非常に明確なメッセージを表示します。
はい、その通りです。VS Codeでは、エディター内で競合がハイライト表示され、現在のもの、新しいもの、または両方を受け入れるオプションが表示されます。ただし、注意が必要です。本当に受け入れたくないのに、誤って「すべて受け入れる」をクリックしてしまうことがよくあります。
現在のブランチの競合は解決されません。ブランチを削除する前に競合を解決しないと、マージ時に競合が残ってしまいます。
単純な重複であれば、Gitは自動的にマージできます。しかし、同じ行やファイルに競合がある場合は、手動で選択する必要があります。魔法のようなことは何もないのです。
まとめ
GitHubで競合を解決する方法を考えるのは必ずしも楽しいことではありませんが、手順を知っておくだけでも大きな違いがあります。ターミナルを使えば制御でき、WebインターフェースとIDEオプションを使えば素早く修正でき、ブランチを短く保つことで将来の競合を防ぐことができます。面倒に感じることもありますが、一度コツをつかめば、ワークフローの一部になります。この記事が皆さんの正しい方向へ進むための助けになれば幸いです。少なくとも、頭を悩ませる時間を少しでも節約できるはずです。
まとめ
- 最新の状態を保つために、メイン ブランチを頻繁にプルしてください。
- 使い慣れたコマンドやツールを使用して競合を解決します。
- 重複を防ぐためにチームメイトとコミュニケーションを取ります。
- マージする前に競合を慎重に確認してください。