Git コンフリクト（衝突）解消方法とは？初心者向けに手順を詳しく解説

はじめに

Gitを使って複数人でプロジェクトを進めていると、ファイルを同時に編集し合った結果、 コンフリクト (衝突) と呼ばれる状態が発生することがあります。
このコンフリクトは初心者の方にとっては厄介に感じられるかもしれませんが、正しい手順とポイントを押さえておけばスムーズに解決できます。

この記事では、初めてGitに触れる方でも理解しやすいように、コンフリクトが起こる仕組みから解消の具体的な手順、そして事前に衝突を減らすためのコツまで詳しくお伝えします。
チーム開発や個人での実習に役立つ実務的な視点も交えながら、どのようにプロジェクト管理をするかイメージしていただけるように構成しました。

Gitを扱う上で、コンフリクトの解消は避けては通れないプロセスです。
しかし、解決方法を理解すれば、作業効率の向上やコミュニケーションをスムーズにする大きな鍵にもなります。
ぜひ最後まで読んでみてください。

この記事を読むとわかること

• Gitコンフリクト（衝突）が起こる具体的な理由
• コンフリクトを事前に防ぐブランチ運用やコミュニケーションのコツ
• コンフリクト発生時の解消フロー（コマンドライン・GUIツール両方）
• リベースやプルリクエストなど実務で生じる場面での対処方法
• チーム開発で衝突を減らすための運用・確認ポイント

ここから先は、実務でよく遭遇するシチュエーションを念頭に置きながら進めていきます。
初心者でも理解しやすいように、難しい専門用語は極力避けつつ、重要な概念は丁寧に説明していきます。

Gitコンフリクト（衝突）とは？

Gitの基本的な仕組み

Gitはファイルの変更履歴を記録し、複数のブランチで作業を並行して進めることを可能にするバージョン管理システムです。
大まかな流れとしては、各開発者がローカルリポジトリで作業し、変更が完了したらステージングしてコミットし、リモートリポジトリにプッシュします。
必要に応じて他の人の作業内容をプルやフェッチして取り込みながら進めるため、チーム内の進捗を同時に管理できます。

この仕組みは便利ですが、同じファイルの同じ部分を別の場所で違う内容に編集していたりすると、どの変更を採用すればよいかGitが自動で判断できなくなる場合があります。
これが コンフリクト (衝突)が起こる基本的な原因です。

コンフリクトが起こる原因

コンフリクトが起こる原因は主に同じ行の内容を異なるブランチで変更していた場合です。
たとえば、Aさんがファイルの10行目を「〇〇」という内容に書き換えた一方、Bさんも同じ行を「△△」に変更し、それぞれがコミット・プッシュすると、マージ（またはプル）時にGitが自動統合できなくなる場合があります。

他にも、ファイルのリネームや削除が並行して行われたときに発生する衝突や、リベース時の差分取り込みなどで発生する複雑なパターンもあります。
どのような形であれ、Git側が「どれを正解として扱うべきか分からない」という状況に陥るとコンフリクトが発生します。

コンフリクトでありがちな実務例

実務では、チーム開発で同じ機能を別々に拡張している際や、急ぎの修正が入るホットフィックスなどでブランチが乱立しているときに衝突が生じやすいです。
また、レビュー前に自分のローカルブランチを最新のメインブランチに合わせようとしたとき、思わぬところでコンフリクトが出ることもあります。

こうした場面では、慌てずに衝突箇所を特定し、どの変更を採用するかコミットメッセージも含めて整理していくのが重要です。
次の章では、そもそもコンフリクトを起こしにくくする運用について解説します。

コンフリクトを事前に回避する方法

ブランチ運用ルールの設定

コンフリクトの発生を抑えるには、ブランチ運用を整理することが効果的です。
代表的な運用例に「Gitフロー」や「GitHubフロー」などがありますが、いずれも基本的には下記のような考え方を共有しておくのが大切です。

• メインブランチは常に安定したコードを置く
• 新しい機能や修正はトピックブランチを切って行う
• マージ前にレビューを実施し、問題がないか確認する

このようなルールを守ることで、なるべく同じ部分を同時に編集しないようにしたり、レビューを通じて不整合を早期に発見したりできます。
結果として、大きなコンフリクトを事前に防ぐことに繋がります。

コミュニケーションの重要性

ブランチ運用だけでなく、メンバー間のコミュニケーションも衝突を減らす重要なポイントです。
たとえば、ある機能を大きく書き換える場合は「このファイルの重要な部分を変更します」と事前に共有し、他の人が同じ箇所を編集しないように調整しておくと衝突のリスクを下げられます。

また、プルリクエストを立てる際にも「どの部分をどう変更したか」「なぜその変更が必要だったか」を丁寧に書く習慣をつけると、レビューの過程で早期に微調整が可能です。
結果的に、大きなコンフリクトが後から発覚するリスクを軽減できます。

マージコンフリクトを解消する基本手順

衝突時に表示されるメッセージを確認する

Gitでマージやプルを実行したときにコンフリクトが起こると、エラーに近いメッセージが表示されます。
このメッセージには「どのファイルのどのあたりに衝突があるか」が書かれているので、まずはそこをチェックしましょう。
複数のファイルで衝突が生じている場合は、1つずつ対処する必要があります。

また、git statusコマンドを使うと、衝突が発生しているファイルが「both modified」などの状態で表示されます。
ここから衝突箇所を特定し、修正を進めていきます。

衝突箇所の編集

衝突があるファイルをテキストエディタやIDEで開くと、以下のようなコンフリクトマーカーが挿入されています。
マーカーの上部が現在のブランチの変更、下部がマージ先（または別のブランチ）の変更です。

コピー
<<<<<<< HEAD
console.log("Hello from HEAD");
=======
console.log("Hello from feature-branch");
>>>>>>> feature-branch

この部分をどのように統合するか自分で編集します。
両方の内容を組み合わせる場合は必要な部分だけを残し、不要な記述や<<<<<<<, =======, >>>>>>>のマーカー行を消し去りましょう。
どちらか一方の変更のみ残したい場合は、不要なほうを削除し、必要なコードだけを残して整形します。

マージ後の再コミット

衝突箇所を修正したら、git add <ファイル名>でステージングし、git commitでマージコミットを作成します。
このときのコミットメッセージは、どのように衝突を解消したか簡単に書いておくと後で振り返る際に便利です。

また、コンフリクトを解消した後は、テストを実行して動作確認をするのが一般的です。
この確認を怠ると、想定外の動作不良が残ったまま次の工程に進んでしまう可能性があります。
コンフリクト解消後は、なるべく早めに動作テストを行い、問題がないかをチェックすることをおすすめします。

具体的な解消の流れ：コマンドライン編

コンフリクト解消手順の例

ここでは、コマンドラインでの作業手順を大まかにまとめます。

1. 最新のリモートブランチをプルする

例：git pull origin main

2. コンフリクト発生箇所を確認する

git status で衝突しているファイルがどれかを把握します。

3. ファイルを開いてコンフリクトマーカーを編集

必要なコードを残し、不要な行を削除します。

4. 編集したファイルをステージング

git add <衝突ファイル>

5. コンフリクト解消用のコミットを作成

git commit -m "コンフリクト解消: ファイル名"

6. 再度プッシュ

git push origin <ブランチ名>

これで、リモートリポジトリにも解消後の状態が反映されます。
もし複数ファイルで衝突している場合は、この流れをそれぞれのファイルで繰り返します。

エラーが出た場合の対処

手順通りに進めても、コミットやプッシュ時に別の衝突やコミット履歴の問題が起こることがあります。
そのときは、再度git statusやgit logで履歴を確認し、どこでトラブルが発生しているかを特定することが第一です。

実務では、リモートブランチとローカルブランチの履歴が大きくずれているケースも起こり得ます。
その場合はチームメンバーと相談しながら、どちらの変更を先に取り込むべきか議論して解決策を決めてください。
状況によっては、一度ローカルのブランチを別名で退避させてやり直すほうがスムーズな場合もあります。

具体的な解消の流れ：GUIツール編

GUIツールを使うメリット

コマンドラインが苦手な方や、視覚的にどこが衝突しているかを捉えたい場合は、GUIツールを活用する方法があります。
たとえば、GitHub DesktopやSourcetree、GitKrakenなどを使うと、衝突している行を比較しながらどの変更を採用するか選ぶことが可能です。

GUIツールを使うと、矢印ボタンなどをクリックするだけでどの変更を残すか決められる機能が用意されていることがあります。
初心者の方にとっては、誤ってマーカーを消し忘れるミスも防ぎやすいので、学習の初期段階ではGUIが便利かもしれません。

GUI上での解消手順

GUIツールごとに細部は異なりますが、大まかな流れはコマンドラインと同じです。
マージやプルを実行し、コンフリクトがあった場合は対象ファイルが「Conflict」と表示されるのでそれをクリックし、衝突している行を確認して修正内容を選択します。
修正が完了したら「解決済み」あるいは「マージ完了」のようなボタンを押すとステージングが行われ、あとはコミットメッセージを入力して完了です。

GUIツールの差分ビューは、どこがどう変更されているかを一目で把握しやすいのが特徴です。
ただし、複雑なコンフリクトだとGUIが少し遅く感じたり、設定画面から細かなオプションを探す必要があったりすることもあるので、慣れてきたらコマンドラインとの使い分けを意識するとよいでしょう。

リベース時のコンフリクト解消方法

リベースがもたらす利点と注意点

Gitのリベースコマンドは、コミット履歴を整理しながら別のブランチの変更を取り込む機能です。
これによって、マージコミットを作らずにスッキリとした履歴を保てますが、その分、コンフリクトが発生した際には手動で解決する必要が出てきます。

リベースを使うと、コミットが別の基底に乗り換える形になるため、「同じ変更が繰り返される」「思わぬ箇所で衝突が起きる」というトラブルが起こることがあります。
そのため、リベースを行う前にしっかり作業ブランチを整理しておくと余計な混乱を減らせます。

リベース中のコンフリクトを解消する流れ

1. git rebase main のようにリベースを実行
2. コンフリクトがあるとプロセスが一時停止するので、git statusで衝突ファイルを確認
3. ファイルを編集してマーカーを取り除き、git addでステージング
4. git rebase --continueでリベースを継続
5. コミットの適用が完了するとリベースが終了

リベースの場合、一連のコミットを再構築している最中に何度も衝突が発生することがあります。
その度に「編集 → ステージ → rebase --continue」を繰り返し、最終的にリベースが完了するまで待ちましょう。
リベースは履歴をきれいに保つ反面、操作を失敗するとやり直すのがやや面倒なので、作業前にブランチをバックアップしておくのも一つの方法です。

実務で役立つテクニック

stashの活用

作業中にちょっと別のブランチをチェックアウトしたいけれど、まだコミットするほど変更がまとまっていないことがあります。
そのときに使えるのが**git stash**です。
作業途中の変更を一時的に退避してブランチを切り替えた後、git stash popで元に戻すという流れを把握しておくと、意図しない形でコンフリクトが起こるリスクを減らせる場合があります。

cherry-pickで特定のコミットだけ取り込む

特定のコミットだけを別のブランチに持ってきたい場合、**git cherry-pick**が役に立ちます。
大規模なブランチのマージやリベースをする必要なく、ピンポイントでコミットを移すことができるため、緊急のホットフィックスなどで活用されることが多いです。

ただし、cherry-pickしたコミットと同じ箇所を別のブランチで変更していた場合、やはりここでも衝突は起こります。
その際のコンフリクト解消方法はマージのときと同じく、ファイルを開いてマーカーを削除して統合します。

チーム開発での衝突対策

コードレビューの徹底

コンフリクトを最小限に抑えるためには、定期的なコードレビューが欠かせません。
プルリクエストの段階で、他の人が似たような箇所を変更していないか、あるいは影響が大きそうな変更を事前にまとめてしまわないかといった視点で確認すると、衝突を未然に防ぎやすくなります。

レビューをする側は、ファイルの差分だけでなく、ブランチの概要や目的を理解しておく必要があります。
単にコンフリクトの有無だけでなく「この変更はどの機能に影響するか」といった点にも気を配りましょう。

プルリクエストのタイミング

プルリクエストを長期間放置してしまうと、メインブランチ（または開発ブランチ）がどんどん進んでいき、いざマージするときに大きな衝突が生じやすくなります。
そのため、小さな変更でもプルリクエストをこまめに出し、早めにレビューやマージを済ませる習慣をつけると、衝突の規模を抑制できます。

よくある疑問とトラブルシューティング

「自分の変更が消えてしまった…」場合

衝突解消時に間違ってコンフリクトマーカーごと相手の変更を残してしまうと、自分の変更が上書きされた形になることがあります。
そのため、コンフリクトが起こったら、どの行を残し、どの行を破棄するかを慎重に確認する必要があります。

もし誤って変更を消してしまった場合は、git reflogやgit logで過去のコミットを探し、自分の変更があった状態を再度チェックアウトすることで復旧を試みられます。
ただし、細かい行単位での復旧は手動で行う必要がある場合が多いので、日頃から小まめにコミットするなどの習慣をつけると安心です。

「マージコミットが多すぎて履歴が複雑…」の場合

マージコミットが頻発すると、Gitのグラフが複雑に見えてしまいます。
この場合はリベースを検討するのも一案ですが、先述の通りリベースは衝突解消の手間が増えるケースもあります。
履歴のわかりやすさを優先するか、マージコミットで確実に時系列が保持される形を優先するかは、チーム方針に応じて決めるとよいでしょう。

Gitコンフリクト解消後の確認作業

手元だけでなくリモートリポジトリも確認する

コンフリクトを解消してローカルでコミットしたあと、必ずリモートリポジトリにも変更をプッシュし、プルリクエストの状況などを確認しましょう。
ローカルでは解消したつもりでも、リモート側がさらに別の変更を取り込んでいて再度コンフリクトが起きることもあります。

プルリクエストを使っている場合は、マージ可能かどうかを確認する画面が表示されます。
緑色で「マージ可能」と表示されれば、基本的にはコンフリクトが解消されています。
万一、まだ「競合しています」のように表示される場合は、再度ローカルでプルして状況を確認してください。

テスト実行や動作確認

コンフリクト解消後は、必ずテストや動作確認を行うのがおすすめです。
コンフリクト解消時に意図せず必要なコードを消してしまったり、逆に不要な行を残してしまったりするケースもあります。
テストコードが用意されているプロジェクトであれば、テストを一通り走らせてみると安心です。

また、Webアプリケーションであればローカルの開発サーバーを立ち上げて、実際にブラウザから挙動を確認してみてください。
チーム開発であればテスト環境やステージング環境にデプロイして、メンバー全員が変更内容を確認できるようにするのも良い方法です。

学習や練習のコツ

コンフリクトを意図的に起こしてみる

初心者の方は、あえて小さなテストプロジェクトでコンフリクトを起こす練習をすると、理解が深まります。
例えば、同じファイルの同じ箇所を別ブランチで違う内容に書き換えてからマージするなど、自発的にコンフリクトを体験してみてください。
実際に衝突してみると、エラー表示から解消手順までの流れが具体的にイメージできるようになります。

コミットを細かく行う

コンフリクトが複雑化すると、大きいコミットのどこで問題が起きているか分からなくなることがあります。
そのため、**「1コミット1つの変更単位」**のように小さな単位でコミットするクセをつけておくと、いざ衝突してしまった場合にも対応しやすくなります。
コミット履歴を見返す際にも、細かく分かれていると原因追及がスムーズです。

まとめ

Gitのコンフリクト（衝突）は、複数人や複数ブランチで同じファイルを編集する以上、避けられない場面といえます。
しかし、ブランチ運用のルールやコミュニケーションを整え、実際に衝突が起きたときには落ち着いて修正箇所を編集すれば、問題なく解決できます。

• コンフリクトの原因は「同じ行を異なる内容で変更していた」ことが主
• 事前に運用ルールとコミュニケーションを徹底すれば、大きな衝突は防ぎやすい
• 衝突が起きても基本手順 (編集 → ステージ → コミット) に従えば問題なし
• リベースやcherry-pickなどを使うと利便性は増すが、衝突リスクも上がる点に注意

最初はコード上で衝突マーカーを見て驚くかもしれませんが、慣れると「どの変更を採用するか」をコントロールできるメリットにも気づくはずです。
きれいな履歴管理と柔軟なブランチ運用は、開発プロジェクトの成功を後押しします。

ぜひ今回の解説を参考にしながら、コンフリクトが発生したときにも余裕を持って対処できるようになってください。
チームでの開発を快適にする大きな一歩となるでしょう。