【Git実践】マージ・コンフリクトを自分で解決する
git コンフリクト 解決 練習 として自分でマージを体験したい、でも「難しそう」「エラーを消せるか不安」と思っていませんか？
この記事では、コンフリクト（衝突）が何なのかを整理したあと、実際にマージして衝突を解消する手順をハンズオン形式で紹介します。Git学習アプリの章5・章8に対応する内容です。
—
> 連載ナビ（全9回）
> G1: git init → G2: git commit → G3: git diff → G4: ブランチ → G5: マージ・コンフリクト（今回） → G6 → G7 → G8 → G9
—
マージとコンフリクトって何？
マージは、「2つのブランチを1つに合わせる操作」です。
前回（G4）でブランチの概念を学びました。「もう一本の道を作って、別の内容を試した」あと、それを元の道に合流させるのがマージです。
ほとんどの場合、Gitは自動的に合流してくれます。でも——
> 同じファイルの同じ場所を、2つのブランチが別々に変更していたら？
そのときGitは「どっちが正しいか自分には判断できない」と判断して、手動で決めてほしいとサインを出します。これがコンフリクト（衝突）です。
エラーではなく、「ここを人間が判断してください」というお知らせです。怖くありません。
—
コンフリクトが起きる仕組みをイメージする
具体例で考えてみましょう。
- `main` ブランチ: `挨拶.txt` の1行目が「こんにちは」
- `feature` ブランチ: 同じファイルの1行目を「おはようございます」に変更
- `main` ブランチ: 別の作業で同じ行を「こんばんは」に変更
この状態でマージしようとすると、Gitは「1行目を『おはようございます』にしたいの？『こんばんは』にしたいの？」と迷います。その結果がコンフリクトです。
—
コンフリクトマーカーの読み方
コンフリクトが起きたファイルを開くと、こんな表示が出てきます。
<<<<<<< HEAD
こんばんは
=======
おはようございます
>>>>>>> feature
3つのマーカーの意味：
| マーカー | 意味 |
|---|---|
| `<<<<<<< HEAD` | ここからが「現在いるブランチ（HEAD）」の内容 |
| `=======` | 境界線（上が現在、下がマージ元） |
| `>>>>>>> feature` | ここまでが「マージしようとしたブランチ（feature）」の内容 |
解決方法はシンプルです。どちらか（または両方を組み合わせた内容）を残して、マーカー3行（`<<<<<<<`, `=======`, `>>>>>>>`）をすべて削除します。
—
実際にコンフリクトを起こして解決してみる
練習用リポジトリを作ってコンフリクトを自分で体験してみましょう。
ステップ1: リポジトリを作って最初のコミットをする
mkdir conflict-practice
cd conflict-practice
git init
echo "こんにちは" > greet.txt
git add greet.txt
git commit -m "最初のコミット"
ステップ2: featureブランチを作って変更する
git switch -c feature
# または旧来の書き方: git checkout -b feature
echo "おはようございます" > greet.txt
git add greet.txt
git commit -m "featureブランチで変更"
ステップ3: mainブランチに戻って別の変更をする
git switch main
# または: git checkout main（古いGit / 初期ブランチがmasterの場合は git checkout master）
echo "こんばんは" > greet.txt
git add greet.txt
git commit -m "mainブランチでも変更"
ステップ4: マージを試みる
git merge feature
こんなメッセージが出てきます。
Auto-merging greet.txt
CONFLICT (content): Merge conflict in greet.txt
Automatic merge failed; fix conflicts and then commit the result.
「自動マージに失敗した。コンフリクトを直してからコミットしてください」という意味です。
ステップ5: コンフリクトファイルを確認する
git status
You have unmerged paths.
(fix conflicts and run "git commit")
Unmerged paths:
(use "git add ..." to mark resolution)
both modified: greet.txt
`both modified` と書かれているのが、コンフリクトしているファイルです。
ステップ6: ファイルを開いてマーカーを確認する
cat greet.txt
<<<<<<< HEAD
こんばんは
=======
おはようございます
>>>>>>> feature
ステップ7: どちらを残すか決めて編集する
今回は「両方を残す」選択をしてみましょう。テキストエディタで `greet.txt` を開いて、マーカー3行を削除し、こう書き換えます。
こんばんは
おはようございます
保存したら、マーカーが消えていることを確認してください。
ステップ8: 解決をGitに伝えてコミットする
git add greet.txt
git commit -m "コンフリクトを解消してfeatureをマージ"
これでコンフリクト解消完了です。
—
Claude Codeに手伝ってもらうプロンプト例
「コンフリクトの内容が複雑でどちらを残すべきかわからない」というときは、Claude Codeに判断の手伝いをしてもらえます。
以下のプロンプトをClaude Codeのチャット欄に貼ってみてください。
—
Gitでコンフリクトが発生しました。次のファイルを確認して、解決方法を提案してください。
対象ファイル: [ファイルパスをここに書く]
コンフリクトの内容:
[ファイルの中身をここにペースト]
このコンフリクトの意味をわかりやすく説明してください。
また、どちらの変更を残すべきか、または両方を統合する場合の書き方を提案してください。
変更を加える前に、対象ファイルと修正内容を確認してから実行してください。
不明点があれば推測せず、確認事項として列挙してください。
—
> 注意: Claude Codeがファイルを直接編集する場合は「実行前に対象ファイルと変更内容を確認してください」と伝えておくと、意図しない上書きを防ぎやすくなります。
—
コンフリクトを減らすための習慣
コンフリクトはゼロにはできませんが、起きにくくする方法があります。
1. ブランチを短命にする: 長期間放置したブランチはコンフリクトが起きやすい。小さい変更をこまめにマージする
2. 同じファイルをなるべく重複して触らない: 役割を分けて作業する
3. マージ前に `git pull` で最新状態にする: リモートの変更を先に取り込んでおく
git switch main
git pull origin main
git switch feature
git merge main
feature ブランチを最新の main に合わせてからマージすると、コンフリクトが起きにくくなります。
—
まだ試行中の部分
コンフリクトを「VSCodeで視覚的に解決する方法」も試しています。VSCodeには3ペインのマージエディタがあり、左・右・中央で3つのバージョンを同時に見ながら選択できます。今後試せたら記事にする予定です。
—
このトピックをアプリで試す
記事で説明した手順は、Git学習アプリの章5・章8で実際にターミナルで動かしながら確認できます。
コンフリクトを意図的に発生させるドリルも用意しているので、ぜひアプリと並べて手を動かしてみてください。
Git学習アプリで実際に試す（GitHubで無料公開中）
> アプリはGitHub上でコードを公開しており、ローカル環境にcloneして動かす形式です（2026年6月時点）。Webアプリ版は `app.maahsachi.com` で公開準備中です。
—
まとめ
- コンフリクトはエラーではなく「人間に判断を求めるサイン」
- `<<<<<<<`, `=======`, `>>>>>>>` の3つのマーカーで「どちらの変更か」を見分けられる
- マーカーを消して好きな内容を残し、`git add` → `git commit` で解決できる
- 複雑なケースはClaude Codeに説明を求めると判断の手がかりになる
次回（G6）は `git restore` で変更をなかったことにする方法を解説します。
—
前回: 【Git実践】ブランチは”もう一本の道”。壊さず試す
次回: 【Git実践】git restoreで”なかったことに”する（準備中）
