前回の記事では、GitHub を使った基本的な開発フローとして、
「main からブランチを切る → 作業 → プルリクを作成 → main へマージ」
という一連の流れを整理しました。
この流れに慣れてくると、次のステップとしてほぼ確実に出会うのが
コンフリクト（conflict） です。
プルリク画面で見かける 「This branch has conflicts that must be resolved」 というメッセージですね。
今回はあえて前編・後編に分けて、まず前編では次のような内容を扱います。
前編ではこれらを通して、コンフリクトの「概念」と「イメージ作り」をしていきます。
実際の解消手順や、「コンフリクトが起きたときどう考えるか」といった話は、後編でじっくり扱います。
チーム開発で大切なブランチ管理
1人で開発しているときは、正直なところ
「main に直接コミットしても動けばOK」 という世界でもなんとかなります。
ですが、メンバーが 2人、3人と増えていくと、「誰が・いつ・どこを変えたか」 を整理しておかないと、
すぐにカオスになってしまいます。
そこで登場するのが、前回の記事でも扱った ブランチ運用 です。
- main（または develop）：常に「正としたい状態」を保つブランチ
- 機能ごとのブランチ：
feature/add-loginのように、小さな単位で作業するブランチ - 修正用ブランチ：
fix/header-styleのように、バグやデザイン修正用のブランチ
このようにブランチを分けることで、
- 今 main に入っているのは「レビュー済みの変更」だけ
- 作業中のコードはそれぞれのブランチの中に閉じこめておける
- 誰がどの機能を触っているか、ブランチ名である程度把握できる
といったメリットが生まれます。
ブランチを「長生き」させないのがポイント
チーム開発でよく起きる問題の1つが、
1つのブランチで長期間作業してしまう ことです。
例えば、
feature/big-changeというブランチで 2〜3週間ずっと作業している- その間に main も別のプルリクでどんどん更新されている
という状況になると、最後にマージしようとしたとき、
「差分が大きすぎてどこがどう変わったのか分からない」 ということになりがちです。
その副作用として、コンフリクトの発生率も一気に上がります。
実務では、次のようなイメージで運用すると、コンフリクトもだいぶ扱いやすくなります。
- 1つのブランチで扱う内容は、できるだけ1つの機能・1つの修正に絞る
- 数日〜1週間くらいで 「作業 → プルリク → レビュー → マージ」 のサイクルを回す
- 途中で main が進んだら、こまめに自分のブランチへ取り込む
この「こまめに取り込む」という部分で使うのが git merge であり、
その結果として起こるのが、この記事のテーマである コンフリクト です。
コンフリクトとは？なぜ発生するのか
まず、コンフリクトを一言で表すと、
「Git がどの変更を採用するべきか自動で決められない状態」
です。
Git はファイルの変化を 行単位 で追いかけています。
そして、ブランチをマージするときに、ざっくり次のようなことをしています。
- 共通の元（base）となるコミットを探す
- base と ブランチA（自分のブランチ）の差分を確認
- base と ブランチB（main など）の差分を確認
- それぞれの変更を「行ごとに」くっつけていく
このとき、
同じ行が両方のブランチで違う内容に変更されていた り、
片方で削除され、片方で修正されていた りすると、Git は迷います。
人間からすると、
- 「自分の修正を採用してほしい」
- 「いやいや、main 側の修正も大事」
という状況ですが、Git にとっては
「どちらが正しいかまでは判断できない」 のです。
その結果、
This branch has conflicts that must be resolved
というメッセージで、
「どの行を残すかは人間が決めてね」 とお願いしてきます。
オートマージとコンフリクトの境目
ここで大事なのが、
「同じファイルを触っている＝コンフリクト」ではない
という点です。
例えば、次のような場合を考えてみます。
- Aさん：
index.htmlの 10〜20 行目を修正 - Bさん：同じ
index.htmlの 50〜60 行目を修正
ファイル名としては同じ index.html を触っていますが、
変更している行が離れている ため、Git は
「この行はAさんの変更、この行はBさんの変更」 と素直に合体させてくれます。
このようなケースでは、GitHub 上のプルリクでも
Able to merge のような表示になり、自動マージが可能です。
逆に、次のようなケースではコンフリクトになります。
- Aさん：
index.htmlの 15 行目を「Aさん用の文言」に変更 - Bさん：同じ 15 行目を「Bさん用の文言」に変更
この場合、Git からすると
「15 行目にはどっちの文言を書けばいいの？」
という状態になり、オートマージできません。
つまり、
- 違う行を変更 → オートマージで OK
- 同じ行を違う内容に変更 → コンフリクトが発生
というのが基本的なイメージです。
よくあるコンフリクトのパターン
もう少し具体的に、よくあるパターンを挙げておきます。
-
同じ行の内容を別々に修正していた
テキスト、変数名、関数の引数など、同じ行を人それぞれの意図で書き換えていたケース。 -
片方で削除・移動し、もう片方で修正していた
Aさんはその行を削除したが、Bさんはまだその行を前提に修正していた、など。 -
ファイルの削除・リネームが絡むケース
Aさんはファイルを削除、Bさんは同じファイルに新しいコードを追加、など。
こうした状況が重なってくると、Git にとっては
「自動では決め切れない」 状態になり、コンフリクトとして人間に判断を委ねてきます。
コンフリクトを減らすためのチェックリスト
コンフリクトそのものは悪いものではありませんが、あまりに頻発するとレビューや検証の手間が増え、
「そもそも何を直したプルリクだったっけ？」 と迷子になりがちです。
最後に、コンフリクトを「ゼロにはならないけれど、減らす」ためのポイントをチェックリスト形式で整理しておきます。
1. プルリク（ブランチ）の粒度を小さくする
- 1つのブランチで扱う内容は、できるだけ 1 トピックに絞る
例：レイアウト修正用・文言修正用・機能追加用などを分ける。 - 「ついで」の変更を詰め込まない
ちょっとしたリファクタや別画面の修正は、別ブランチに分けた方がコンフリクトも追いかけやすくなります。 - 長生きブランチを作らない
数週間育てたブランチほど、マージ時のコンフリクトが大きくなりがちです。
2. main（または開発用ブランチ）をこまめに取り込む
- プルリクを出す前に一度 main を取り込む
GitHub の「Update branch」ボタンやgit merge origin/mainで、最新の変更を反映してからレビューに出します。 - 長めの作業になりそうなときは途中でもマージ
1〜2日おきに main を取り込んでおくと、コンフリクトが出ても「小さいうちに解決」できます。
3. ファイルの「担当エリア」をざっくり決める
- よく触るファイルほど、担当者やルールを決める
例：共通レイアウトはAさんが中心、APIクライアントまわりはBさんが中心、など。 - 大きめのリファクタは事前に共有する
「この画面の HTML を全部組み替えます」といった大変更は、先に一言共有しておくだけでも、他の人が同じ箇所を触るリスクを減らせます。
4. 設定ファイル・依存アップデートは慎重に
- 設定ファイルや共通コンポーネントの変更は、専用のブランチでまとめて行う
例：package.jsonや CI 設定、共通レイアウトなど。 - 「ついでに」いじらない
本筋と関係ない設定変更を一緒に混ぜると、別のブランチでも同じファイルを触りやすくなり、コンフリクトの温床になります。
5. チーム内で最低限のルールを言語化しておく
- プルリク前に main を取り込む
- 1プルリク1トピックを基本ルールにする
- 大きな変更は Slack などで事前に共有する
といった、ごくシンプルなルールでも、明文化されているだけでコンフリクトの発生頻度とダメージはかなり変わってきます。
コンフリクトを完全に避けることはできませんが、
「起きる場所とタイミングをコントロールする」 ことで、ずいぶん付き合いやすくなります。
まとめ（後編へのつなぎ）
前編では、GitHub のコンフリクトについて、
- チーム開発ではブランチ管理が重要で、ブランチを「長生きさせない」ことがポイント
- コンフリクトは、同じ行の変更を Git が自動で決められないときに発生する
- 同じファイルでも、違う行を変更しているだけならオートマージされる
- チェックリストのように、運用ルールを少し整えるだけでもコンフリクトは減らせる
といった内容を中心に、「コンフリクトとは何か」 のイメージ作りと、実務での付き合い方の工夫を整理しました。
後編では、
- コンフリクトが起きたときに、GitHub 上でどう解消していくか
- ローカルでのコンフリクト解消パターン
- 「コンフリクト＝悪」ではなく、「調整のサイン」として捉える考え方
といったテーマを扱いながら、
「コンフリクトが起きても怖くない状態」 を目指していきます。
新着情報
ブログランキングに参加しています。クリックして応援していただけると嬉しいです。
