（最終更新月：2023年8月）
✔当記事は以下の疑問を抱える方へ向けて書かれています
「gitのコンフリクトが何なのかを正確に理解したい」
「gitでコンフリクトが発生したときの対処法を知りたい」
「gitコンフリクトの解消例を見て学びたい」
✔当記事を通して得られる知識
- gitコンフリクトの原理とその理由
- gitコンフリクト発生時の具体的な対策と解消法
- gitコンフリクトの解決例
当記事では、gitのコンフリクトについて、なぜ発生するのかの基本から、発生した際の対処法、さらには具体的な解決例まで実例を交えて詳しくご紹介します。
最後までご一読いただけますと幸いです。
筆者プロフィール
【現職】プロダクトマネージャー
【副業】ブログ（月間20万PV）/YouTube/Web・アプリ制作
「プログラミング × ライティング × 営業」の経験を活かし、30後半からのIT系職へシフト。現在はプロダクトマネージャーとして、さまざまな関係者の間に入り奮闘してます。当サイトでは、実際に手を動かせるWebアプリの開発を通じて、プログラミングはもちろん、IT職に必要な情報を提供していきます。
【当ブログで紹介しているサイト】
✔人に見せても恥ずかしくないコードを書こう
「リーダブルコード」は、わかりやすく良いコードの定義を教えてくれる本です。
- 見るからにきれいなコードの書き方
- コードの分割方法
- 変数や関数の命名規則
エンジニアのスタンダートとすべき基準を一から解説しています。
何回も読むのに値する本なので、ぜひ手にとって読んでみてください。
Gitコンフリクトを理解するための前提知識
こちらでは、Gitについての基本からお伝えしていきます。
- Gitとは何か？
- Gitにおけるコンフリクトとは
Gitとは何か？
Gitは、プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムです。
複数の開発者が同じプロジェクトに対して同時に作業を行う際に、各開発者の作業を管理し、必要に応じて統合する役割を果たします。
Gitにおけるコンフリクトとは
git のコンフリクトは、複数の開発者が同時に同じファイルの同じ部分を変更しようとした際に発生する問題です。
コンフリクトが発生すると、git は自動的にマージできず、人間の介入が必要になります。
これは、git がどちらの変更が正しいのか、あるいは両方の変更をどのように統合すればよいのかを自動的に決定することができないからです。
コンフリクトが発生すると、以下のようなメッセージが表示されます。
CONFLICT (content): Merge conflict in <file>
Automatic merge failed; fix conflicts and then commit the result.コンフリクトが発生したファイルを開くと、git はコンフリクトした部分を以下のようにマークします。
<<<<<<< HEAD
(現在のブランチでの変更部分)
=======
(マージしようとしているブランチでの変更部分)
>>>>>>> <commit-hash>ここで、開発者は手動でこの部分を修正し、どちらの変更を採用するのか、または両方の変更をどのように統合するのかを決定します。
修正が完了したら、変更をコミットしてマージを完了します。
コンフリクトの解消は、コードの意図を正確に理解し、どの変更が正しいかを慎重に判断する必要があり、時には難しい作業になるのです。
コンフリクトが発生する状況とその前提
次に、コンフリクトが発生する具体的な状況とその前提を解説します。
- ブランチの存在とその役割
- コンフリクトが起こる主な原因
ブランチの存在とその役割
gitのブランチは、プロジェクトの異なるバージョンを分岐させる機能です。
ブランチを使うことで、同じコードベース上で、複数の開発ラインを同時に進行させられます。
以下は、ブランチがよく使用されるシチュエーションと役割です。
- 機能開発
新しい機能や変更を開発する際、メインブランチから分岐させることで、ほかの開発者と独立して作業できます。開発が完了し、テストなどが終わったらメインブランチにマージしましょう。 - バグ修正
バグの修正をおこなう際に専用のブランチを作成することで、ほかの開発作業と並行できます。 - 実験
アイデアを試すためのブランチを作ることで、他の開発に影響を与えずに実験できます。 - リリース管理
リリース用のブランチを作ることで、プロダクション環境にデプロイされるバージョンのコードを管理しやすくなります。 - コードレビュー
変更をほかのチームメンバーにレビューしてもらう前に、ブランチにプッシュすることが一般的です。
ブランチの使用によって、開発プロセスがより柔軟かつ効率的になります。
特定のタスクに集中しながら、チーム全体の進行と調和を保つことができるため、多人数での開発において非常に重要な概念です。
コンフリクトが起こる主な原因
コンフリクトが起こる主な原因として、同じファイルの同じ部分を異なるブランチやコミットで同時に変更する場合などが挙げられます。
これは以下の状況で発生することが一般的です。
- 同時に同じファイルを編集
- 長い間ブランチをマージしていない
- 不適切なブランチ戦略
- 適切なコミュニケーションがない
- 直線的でない歴史のリベース
同時に同じファイルを編集
複数の開発者が同時に同じファイルの同じ部分を編集しているときにおこります。
ブランチをマージする際にどちらの変更が採用されるべきかをgitが自動的に判断することができないことが原因で、コンフリクトが発生してしまいます。
長い間ブランチをマージしていない
長期間にわたってブランチをマージしない場合にも、コンフリクトが起こりやすくなります。
別々に開発を進めて、多くの変更が積み重なり、最終的なマージでコンフリクトが発生してしまうのです。
不適切なブランチ戦略
一貫性のない、または明確でないブランチ戦略があると、予期せぬコンフリクトが発生することがあります。
なぜならどのブランチで何をおこなうべきかが不明確で、同じファイルを編集してしまうことがあるからです。
適切なコミュニケーションがない
チームメンバー間のコミュニケーションが不足していると、コンフリクトを引き起こす可能性があります。
同じタスクやファイルに対して同時に作業してしまうことがあるからです。
直線的でない歴史のリベース
gitのリベース操作を不適切におこなうことが、コンフリクトの原因となる場合があります。
既存のコミット履歴を変更してしまうことに繋がってしまうからです。
実際のコンフリクト発生例
ここでは、実際にコンフリクトが発生したときの表示を説明します。
- 新機能とバグ修正の同時開発
- 長期ブランチでの並行開発
- リベースによるコンフリクト
新機能とバグ修正の同時開発
開発者Aさんは、新機能の開発のためにブランチAを作成し、ファイルXの一部を変更します。
一方、開発者Bさんは、同じファイルXの同じ部分にバグがあることに気付き、ブランチBで修正をおこないました。
AliceとBobがそれぞれの変更を完了し、マージしようとすると、同じ場所に対する異なる変更があるため、コンフリクトが発生してしまうでしょう。
長期ブランチでの並行開発
チームは新しい大規模な機能を開発するためにブランチCを作成し、数ヶ月間作業します。
その間に、メインブランチでは小さな改善と修正が継続的におこなわれ、同じファイルに多くの変更が加えられます。
長期ブランチCをメインブランチにマージしようとすると、多くのコンフリクトが発生する可能性があります。
これは、両方のブランチでの変更が積み重なり、相互に影響し合うためです。
リベースによるコンフリクト
開発者Dさんは、ブランチDで作業し、その間にメインブランチに新しいコミットが追加されました。
開発者Dさんは、ブランチDを最新のメインブランチにリベースしようとしますが、メインブランチで変更された部分とブランチDで変更された部分が衝突します。
この結果、リベース操作中にコンフリクトが発生し、開発者Dさんは手動でこれを解決しなければなりません。
コンフリクト解消プロセスの実例
コンフリクトの解消には具体的な手順が必要となります。
以下では、それぞれの手順を紹介します。
- 解消前後の状態の確認
- 実際の差分の確認と編集
- 編集したファイルのステージング
- commitとpushまでの手順
- コンフリクト解消後のログ確認
解消前後の状態の確認
コンフリクトが発生した場合、まず git status コマンドを使用して、どのファイルにコンフリクトが発生したかを確認します。
git statusこれにより、コンフリクトが発生したファイルがリスト表示されます。
実際の差分の確認と編集
コンフリクトが発生したファイルをテキストエディタで開き、Gitが表示するコンフリクトマーカー（<<<<<<<, =======, >>>>>>>）を探します。
<<<<<<< HEAD
(現在のブランチでの変更部分)
=======
(マージしようとしているブランチでの変更部分)
>>>>>>> <commit-hash>これらのマーカーの間にあるコードがコンフリクトしている部分です。
開発者はこの部分を適切な状態に編集する必要があります。
編集したファイルのステージング
コンフリクトが解消されたファイルは、次にステージングエリアに追加する必要があります。
これは git add コマンドで行います。
git add filenamecommitとpushまでの手順
ステージングした後、変更を確定（commit）し、リモートリポジトリに変更を反映（push）します。
git commit -m "コンフリクトの解消"
git pushコンフリクト解消後のログ確認
コンフリクトの解消後、git log コマンドを使用して、変更が正しく記録されていることを確認します。
git logこれにより、コミットの履歴が表示され、コンフリクトの解消が適切に行われていることが確認できます。
コンフリクトを防止するためのポイント
次に、コンフリクトを防止するためのポイントを紹介します。
- 並行開発の管理
- 常に最新のファイルを使用する
並行開発の管理
複数人で同じプロジェクトに取り組む場合、開発の進行管理が重要です。
具体的には、各開発者が何を担当し、どのブランチを使用しているのかを明確にしましょう。
定期的にメインブランチにマージを行い、コンフリクトが発生した場合はすぐに解消することも大切です。
常に最新のファイルを使用する
自身の作業ブランチにおいて、可能な限りメインブランチの最新状態を取り込みましょう。
なぜならほかの人がおこなった変更と、差分が発生しにくくなるからです。
git pull origin mainQ&A：よくある質問
以下にて、gitのコンフリクトに関連するよくある質問をまとめました。
事前に理解しておけば、トラブル時の解決に必ず役立つでしょう。
コンフリクトを自分で解決できない場合はどうすればいいですか？
コンフリクトが解決できない場合、以下のステップを試してみるとよいでしょう。
- 関係する他の開発者やチームメンバーに助けを求める。
- コンフリクトの箇所のコードの履歴を調べる (
git log <file>,git blame <file>などを使用) して、変更の意図を理解する。 - 必要に応じて、一時的に変更を保存して作業をリセットする。(
git stashやgit resetを使用)
リベースとマージのどちらを使うとコンフリクトが少なくなるのですか？
リベースとマージのどちらを使うべきかは、特定の状況やチームのワークフローに依存します。
リベースはコミット履歴を線形に保つために使用されますが、既存のコミットのタイムラインを変更することがあります。
一方、マージはコミット履歴の分岐を保持します。
コンフリクト自体は、リベースでもマージでも同じ場所で同様に発生する可能性があるため、どちらがコンフリクトを減らすかは一概に言えません。
コンフリクトの解決後、コードが正しく動作しない場合はどうすればいいですか？
コンフリクトの解決後にコードが正しく動作しない場合、以下の手順を実行できます。
- コンフリクトを解消した箇所を再検討し、変更が正しいことを確認します。
- 既存のテストを実行し、新しいテストケースを追加して問題を特定します。
- チームメンバーやコードのオーナーとコミュニケーションを取り、問題の解決に取り組みます。
- 必要に応じて、変更を一時的に元に戻して (
git revertやgit resetを使用)、再度解決プロセスを開始します。
コンフリクトの解決は複雑なプロセスであることが多く、特定の問題を解決するためにチームと連携することが重要です。
まとめ
当記事では、Gitコンフリクトについて学習してきました。
コンフリクトはマルチプレイヤーのプロジェクトで避けられない現象であるため、効果的に解消するスキルは必須です。
これらの知識とスキルを活用して、チーム全体の生産性とプロジェクトの成功に貢献してください。