【Git】コンフリクト解消はもう怖くない！現場で迷わない具体的な手順

Gitのマージ時に発生する「競合」に、焦りや不安を感じていませんか？本記事では、Gitの競合解消の仕組みから、コマンドやVS Codeを使った具体的な手順、未然に防ぐコツまでを網羅して解説します。マーカーの読み方や安全な操作フローを理解すれば、初心者でも落ち着いて対処可能です。競合を恐れず、自信を持ってチーム開発を進めるための実践的なスキルを身につけましょう。

記事のポイント

• 競合が発生する仕組みと「<<<<<<<」などのマーカーの読み方を理解することで、修正すべき箇所を正確に特定できるようになります。
• 競合解消は「確認・修正・再コミット」の3ステップで進めるのが基本であり、初心者でも迷わず対応できる標準的なフローを解説しています。
• VS Codeなどのエディタ機能を活用することで、複雑な競合も視覚的にミスなくスムーズに解決するテクニックが身につきます。
• 万が一作業に迷ってもコマンド一つで安全にやり直せる方法を知ることで、心理的なハードルを下げてトラブルに対処できるようになります。
• 頻繁なプルや小まめなコミットといったベストプラクティスを実践し、チーム開発で競合の発生自体を最小限に抑える習慣が身につきます。

Gitで競合が発生する原因と解消に向けた基本的な考え方

Gitを利用したチーム開発において、避けて通れないのが 競合（コンフリクト） です。このセクションでは、なぜ競合が発生するのかというメカニズムから、解消に向けた基本的なプロセス、そして心理的なハードルを下げるための考え方について解説します。

競合（コンフリクト）が発生する仕組みと主な原因

Gitの競合は、複数の変更を統合（マージやリベース）しようとした際、Gitが「どの変更を優先すべきか自動で判断できない」状態になったときに発生します。Gitは主に行単位の差分アルゴリズムを用いて変更を比較しますが、機械的な判別が不可能なケースがいくつか存在します。

主な原因を以下の表にまとめました。

特に 「同じ箇所の書き換え」 は最も頻繁に遭遇するパターンであり、開発者同士のコミュニケーションや作業範囲の調整が重要となる場面でもあります。

競合を解消するために必要な3つの基本ステップ

競合が発生しても、落ち着いて以下の 3つのステップ を踏むことで、確実に解決へと導くことが可能です。

1. 現状の把握（Identify） まずは git status コマンドを実行し、どのファイルで競合が起きているのかを正確に特定します。競合状態にあるファイルは「both modified」などのステータスで表示されます。
2. ソースコードの修正（Resolve） 対象のファイルを開き、Gitが挿入したコンフリクトマーカー（後述）を頼りに、どちらのコードを残すか、あるいは両方を組み合わせて新しいコードにするかを手動で判断し、編集します。
3. 変更の確定（Finalize） 修正が完了したら、 git add で修正済みであることをGitに伝え、 git commit （リベースの場合は git rebase --continue ）を行うことで、統合プロセスを完了させます。

Kindle Unlimited

IT専門書も30日間無料で読み放題

1冊数千円する専門書から、ビジネス書、実用書、雑誌まで幅広いジャンルが定額で読み放題。ITスキルの向上はもちろん、日々の情報収集や教養を深めるのにも最適です。

• 📚 技術書も月額定額で読み放題
• 📱 マルチデバイス対応
• ✨ 30日間の無料体験

無料で30日間試してみる

競合を恐れずに解消するための安全な作業の重要性

初心者にとって、競合の発生は「壊してしまったのではないか」という不安を感じさせるものかもしれません。しかし、競合はエラーではなく、 「データの整合性を守るためのGitの安全装置」 であると捉えるのが健全な考え方です。

安全に作業を進めるためには、以下のポイントを意識すると良いでしょう。

• 作業前にブランチのバックアップを取る: 不安な場合は、マージ操作の前に現在のブランチから一時的なバックアップブランチを作成しておくと、いつでも元の状態に戻せます。
• 独断で判断しない: 競合した箇所が自分以外の担当範囲である場合、関係者に意図を確認することが、バグの混入を防ぐ最も確実な方法といえます。
• 小さな単位でプル（マージ）する: 長期間ブランチを放置せず、頻繁にベースブランチの変更を取り込むことで、一度に発生する競合の量を最小限に抑えられる可能性があります。

競合解消は、コードの意図を再確認し、チーム内での認識を合わせるための コードの整合性を保つための重要なプロセス であると捉えて取り組んでいきましょう。

Gitの競合を確実に解消するための具体的な手順とツール活用

競合が発生した際、パニックにならずに済むかどうかは「何が起きているか」を正確に把握できるかにかかっています。ここでは、Gitが提示する情報の読み解き方から、コマンドラインやモダンなエディタを用いた具体的な解消手順、そして競合を未然に防ぐための工夫について解説します。

競合発生時のログサンプル（ターミナル出力例）

実際に競合が発生した際、ターミナル（コマンドプロンプトやターミナルなど）には以下のようなログが表示されます。これを知っておくことで、「何が起きているのか」をすぐに判断できるようになります。

git merge 実行時のログ

git merge や git pull を実行して競合が発生すると、末尾に「Automatic merge failed」というメッセージが表示されます。

1
$ git merge feature-branch
2
Auto-merging index.md
3
CONFLICT (content): Merge conflict in index.md
4
Automatic merge failed; fix conflicts and then commit the result.

git status 実行時のログ

競合が発生している状態で git status を実行すると、どのファイルが競合しているのか（both modified）を確認できます。

1
$ git status
2
On branch main
3
You have unmerged paths.
4
  (fix conflicts and run "git commit")
5
  (use "git merge --abort" to abort the merge)
6

7
Unmerged paths:
8
  (use "git add <file>..." to mark resolution)
9
  both modified:   index.md
10

11
no changes added to commit (use "git add" and/or "git commit -a")

コンフリクトマーカー（<<<<<<<）の読み方と修正方法

Gitは競合が発生した箇所を、特殊な記号である 「コンフリクトマーカー」 で囲んで示します。この記号の意味を正しく理解することが、解消への第一歩です。

1
<<<<<<< HEAD
2
現在のブランチ（自分側）での変更内容です。
3
=======
4
マージしようとしているブランチ（相手側）での変更内容です。
5
>>>>>>> branch-name

競合箇所を見つける方法とマーカーの再表示方法

大きなファイルで競合が発生した場合や、誤ってマーカーを消してしまった場合には以下の方法が有効です。

• テキスト検索: エディタ（VS Codeなら Ctrl + F）で <<<<<<< を検索するのが最も確実です。
• grepコマンド: ターミナルで grep -n '``<<<<<<<``' [ファイル名] と実行すれば、行番号を含めて特定できます。
• マーカーの再表示: 編集ミスでマーカーを消してしまい、最初からやり直したい場合は以下のコマンドを実行すると、そのファイルの競合マーカーがリセット（再表示）されます。

  1
  git checkout -m [ファイル名]

応用：より詳細な情報を表示する「diff3」スタイルへの切り替え

デフォルトでは「自分側（HEAD）」と「相手側」の2つの差分しか表示されませんが、以下の設定を行うことで 「共通の親（マージベース：両ブランチの共通祖先）」 も含めた3方向の比較が可能になります。

1
# グローバル設定を「diff3」に切り替える
2
git config --global merge.conflictStyle diff3

この設定を有効にすると、マーカーの間に ||||||| base というセクションが追加されます。

1
<<<<<<< HEAD
2
（自分側の変更内容）
3
||||||| base
4
（共通の親：変更が加わる前の元の状態）
5
=======
6
（取り込もうとしている相手側の変更内容）
7
>>>>>>> branch-name

「元々どんなコードだったか」を直接確認できるため、複雑なロジックが絡む競合でも「何がどう変わったのか」を正確に把握しやすくなります。

具体的な解決例：Before & After

言葉だけではイメージしづらい「競合の解決プロセス」を、具体例で確認しましょう。

1. 競合した直後の状態（Before）

同じ行を自分と相手で別々に書き換えてしまったケースです。

1
``<<<<<<<`` HEAD
2
console.log("こんにちは、世界！"); // 自分の変更
3
=======
4
console.log("Hello, World!"); // 相手の変更
5
>>>>>>> feature-branch

2. ファイルを編集する（解決作業）

どちらの内容を残すか、または両方を組み合わせるかを検討し、 コンフリクトマーカー（<<<<<<<, =======, >>>>>>>）も含めて 最終的に正しい形に書き換えます。

ここでは「（多言語対応のために）両方の内容を順番に表示する」という判断を下したとします。

1
/* greeting.js (編集後の内容) */
2
console.log("こんにちは、世界！");
3
console.log("Hello, World!");

状況別：よくある3つの編集パターン

競合の内容に応じて、以下の3つのいずれかの方法でファイルを編集します。

相手側（相手の変更）だけを残したい場合の編集イメージ

例えば、相手の内容だけを採用したい場合は、以下のように 不要な行をすべて削除 し、相手のコード行だけが残るようにします。

1
【編集前】
2
``<<<<<<<`` HEAD
3
（自分側の変更：ここを削除）
4
=======
5
（相手側の変更：これだけを残す！）
6
>>>>>>> branch-name

1
【編集後】
2
（相手側の変更のみが記述された状態）

3. 解決を確定させる（After）

マーカーが消え、ファイルが正しい状態になったら、ターミナルで以下のコマンドを実行して統合を完了させます。

1
git add greeting.js
2
git commit -m "Merge branch 'feature-branch' and resolve conflict in greeting.js"

「マーカーをすべて消して、最終的にあるべきコードの状態に整える」。これさえ徹底すれば、どんな複雑な競合も確実に解決できます。

コマンドライン操作による競合解消の標準的な実行フロー

コマンドラインで競合を解消する場合、以下の手順で進めるのが一般的です。

1. 競合ファイルの特定: git status を実行し、 both modified と表示されているファイルを確認します。
2. ファイルの編集: テキストエディタで該当ファイルを開き、コンフリクトマーカーを目印にコードを修正します。
3. ステージング: 修正が完了したら、 git add ＜ファイル名> を実行して「解消済み」であることをGitに伝えます。
4. コミットの完了: 通常は git commit を実行します（状況によっては git merge --continue を使用できる場合もあります）

VS Codeなどのエディタ機能を活用した効率的な競合解消テクニック

Visual Studio Code（VS Code）などのモダンなエディタには、競合解消を視覚的に支援する 「マージエディタ」 機能が備わっています。

• ボタン操作による選択: 「Accept Current Change（現在の変更を採用）」や「Accept Incoming Change（取り込む変更を採用）」といったボタンをクリックするだけで、マーカーの削除を自動で行えます。
• サイドバイサイド比較: 左右にそれぞれのブランチの変更を表示し、下部に最終結果を表示するUIにより、 複雑なロジックの競合でもミスを防ぎやすく なります。

手動編集によるタイポやマーカーの消し忘れを防ぐため、慣れないうちはエディタの支援機能を積極的に活用することをおすすめします。

競合の発生を最小限に抑えるためのチーム開発のベストプラクティス

競合は避けられないものですが、その頻度や難易度を下げることは可能です。

• こまめにプル（マージ）を行う: 自分のブランチを長く放置せず、ベースとなるブランチ（mainなど）の最新の変更を頻繁に取り込むことで、一度に発生する競合の量を抑えられます。
• プルリクエスト（PR）を小さく保つ: 変更範囲が広すぎるPRは、他の作業者と競合する確率を高めます。機能ごとに小さく分割して開発を進めるのが理想的です。
• フォーマッタを統一する: ESLintやPrettierなどのツールを使い、チーム全員でコードの書き方を統一しましょう。インデントや改行の違いによる「不必要な競合」を防げます。

競合解消後にミスを防ぐための振り返りチェックリスト

競合を解消した直後は、焦りや集中力の低下からケアレスミスが発生しやすくなります。以下のチェックリストを活用して、最終的な確認を行うことが推奨されます。

Gitの競合解消に関するまとめとよくある質問

今回のまとめ：振り返りチェックリスト

• 競合はエラーではなく「Gitが自動で判断できない変更の重なり」であることを理解し、まずはコンフリクトマーカーを正しく読み解いて、どちらのコードを残すべきか冷静に判断しましょう。
• 修正時はVS Codeなどのエディタ支援機能を活用して視覚的に解消し、作業後には必ずビルドやテストを行って「正しく動く状態」であることを確認する習慣をつけましょう。
• 万が一、解消作業中に混乱してしまったら git merge --abort で一旦リセット。無理に進めて不具合を生む前に、安全にやり直したりチームに相談したりする勇気を持つことが大切です。
• アドバイス： 競合を最小限に抑えるコツは、日頃から「こまめなプルとコミット」を繰り返すことです。もし競合が発生しても、この記事の手順を一つずつ踏めば確実に解消できるので、自信を持って取り組んでくださいね！

Gitの競合（コンフリクト）は、複数の開発者が同じ箇所を編集した際に発生する自然な現象です。大切なのは、競合を発生させないこと以上に、 「発生した際にいかに正確かつ安全に解消するか」 という点にあります。本セクションでは、作業後の確認ポイントと、現場でよくある疑問への回答をまとめました。

Gitの競合解消に関するFAQ

Gitの操作中に迷いやすいポイントをQ&A形式で解説します。

Q. 競合解消の作業を途中で最初からやり直したい（中止したい）場合は？

解消作業中に「どのコードを残すべきか分からなくなった」「操作を間違えてぐちゃぐちゃになった」という場合は、マージ操作自体を中止して、競合が発生する前の状態に戻すことができます。

1
# マージ作業を開始する前の状態に完全に戻す
2
git merge --abort
3
# リベース作業を完全にキャンセルして、元の履歴に戻す
4
git rebase --abort

このコマンドを実行することで、 マージを開始する前のクリーンな状態 に安全に戻ることができます。無理に手動で直そうとせず、一度リセットして冷静にやり直すのも一つの手です。

Q. どちらの変更を採用すべきか自分一人で判断できない場合は？

自分だけの判断でコードを書き換えると、他のメンバーが実装した重要なロジックを誤って削除してしまう恐れがあります。

• git blameを活用する: git blame [ファイル名] コマンドを実行して、該当箇所を最後に編集した担当者を確認しましょう。
• 担当者に相談する: Slackなどのチャットツールや口頭で「この部分で競合が起きたのですが、どちらのロジックを優先すべきですか？」と確認するのが最も確実です。
• ペアプログラミング: 複雑な競合の場合は、関係者と一緒に画面を見ながら解消作業を行うことで、ミスを未然に防げる可能性が高まります。

競合解消は単なる技術的な作業ではなく、 チームメンバーとのコミュニケーション を通じてコードの品質を担保する重要なプロセスといえます。

参考リンク:

• Git 公式ドキュメント - git-merge
• Git 公式ドキュメント - Basic Merging
• Atlassian Git Tutorial - 競合の解決
• Microsoft VS Code 公式ドキュメント - Merge conflicts

Gitユーザにお勧めの本

初心者向け

いちばんやさしいGit&GitHubの教本 第3版 人気講師が教えるバージョン管理＆共有入門 「いちばんやさしい教本」シリーズ

Amazonで詳細を見る 🔴 楽天で見る

改訂2版 わかばちゃんと学ぶ Git使い方入門

Amazonで詳細を見る 🔴 楽天で見る

独習Git

Amazonで詳細を見る 🔴 楽天で見る