🔧Git・GitHub完全入門：現場で役立つコンフリクトの解決方法【実例＆ベストプラクティス】

1. はじめに〜なぜコンフリクトは避けられないのか？

Gitをチーム開発で使っていると、**必ず一度は出会うのが「コンフリクト（conflict）」**です。

🙋‍♀️「え、マージしようとしたら CONFLICT の文字が出てきた…怖すぎて何もできない…」

こんな経験、ありませんか？

でも大丈夫。コンフリクトはエラーではなく、「Gitが判断できない変更点を人間に確認してほしい」だけです。
本記事では、現場でよく起こるコンフリクトの具体例をもとに、「安心して、確実に、冷静に」解消する方法を詳しく紹介します。

2. コンフリクトとは何か？概要と発生の仕組み

💡そもそもGitの仕組み

Gitは「分散型バージョン管理システム」で、各開発者がローカルにリポジトリを持ち、変更を後で統合（マージ）します。

しかし、同じファイルの同じ行を複数人が変更した場合、Gitは「どれが正しいのか」を判断できません。
このとき発生するのが「マージコンフリクト（merge conflict）」です。

3. 【実践】よくあるコンフリクトの例と解決方法

ここでは実際にmainブランチとfeature/add-readmeブランチを使って、コンフリクトの解消を体験してみましょう。

🧪前提：リポジトリ構成

$ git init git-conflict-demo
$ cd git-conflict-demo
$ echo "Hello, World!" > README.md
$ git add README.md
$ git commit -m "初回コミット"
$ git checkout -b feature/add-readme

📝Step 1: ブランチごとにREADMEを編集

# featureブランチで編集
$ echo "このプロジェクトはGit学習用です。" >> README.md
$ git commit -am "READMEに説明文追加"

# mainブランチに戻って別の編集
$ git checkout main
$ echo "これはサンプルリポジトリです。" >> README.md
$ git commit -am "READMEに別の説明を追加"

💥Step 2: マージしてコンフリクト発生！

$ git merge feature/add-readme
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.

🛠Step 3: コンフリクトの内容を確認

# README.md の内容が以下のようになっているはず

Hello, World!
<<<<<<< HEAD
これはサンプルリポジトリです。
=======
このプロジェクトはGit学習用です。
>>>>>>> feature/add-readme

この <<<<<<<, =======, >>>>>>> の記号は、Gitがどの変更を残すかユーザーに任せているサインです。

✅Step 4: 解決してコミットする

Hello, World!
このプロジェクトはGit学習用です。これはサンプルリポジトリです。

その後、以下のようにマージ完了：

$ git add README.md
$ git commit -m "コンフリクト解消: READMEを統合"

4. 現場で役立つTips＆落とし穴

✅ 実践Tips

**マージの前にgit fetch＋git rebase**を心がけよう
→ できるだけ早い段階でコンフリクトを表面化
小まめにコミットしよう
→ 差分が明確になり、どこで衝突したか把握しやすい
GUIツールの活用もOK（VSCode、Sourcetreeなど）

❌ よくある失敗

パターン	問題点
`git checkout --ours` や `--theirs` を無意識に使う	必要な変更を消してしまうリスク大
コンフリクト部分を手作業で削除 → add → commit	解決したと思ってpushしたら「中身が空」だった…

5. 応用：3人以上での同時開発でのコンフリクト対応

🎯Case：チーム開発での衝突回避戦略

プルリクエスト（Pull Request）を細かく分ける
main 直push禁止＆CIの整備
変更が重なるファイルは明示的に担当者を決める

🔄 rebase vs merge：どちらを使うべき？

rebase	merge
履歴がきれい（直線的）	履歴が実際の流れを残す
履歴改変がある	履歴はそのまま
コンフリクトが小さいとき有利	履歴共有やリリース後の追跡が必要な場合向き

6. まとめ：コンフリクトを恐れず、味方にしよう！

✅メリット

チームのコード品質を担保するプロセスの一部
複数人開発での整合性チェックになる
解消スキル＝現場力が高まる！

⚠デメリット

経験が浅いと精神的ストレス大
長期間放置すると複雑化

🔮今後の展望

Gitは今後もチーム開発に欠かせないツールです。
AIベースのコードマージ支援（GitHub Copilotなど）も登場し、コンフリクト解決もさらに進化しています。

とはいえ、仕組みを正しく理解しておくことは変わらず重要。
ぜひ今回紹介した手順を参考に、あなたのプロジェクトでも「コンフリクト解決、もう怖くない！」を実現してください。

📘 参考資料