章: 第7章: チーム運用を安定させる設計
コンフリクトそのものより、慌てた解消の方が危ない
Gitでよく怖がられるのがコンフリクトです。確かに画面に見慣れない印が出るので、最初は身構えやすいです。
しかし実務で本当に危ないのは、コンフリクトが起きること自体ではありません。
コンフリクトを急いで雑に解消して、本来残すべき変更を消してしまうことの方が危険です。
そのため大事なのは、「コンフリクトは異常事態」ではなく「人間の判断が必要な状態」と理解することです。
どんなときに起きるのか
コンフリクトは、同じ箇所や近い箇所を別のブランチで変更していたときに起きやすいです。
- 同じ関数の同じ行を両方で修正した
- 片方で削除し、片方で追加した
- 並び順や構造を互いに変えていた
つまりGitが悪いのではなく、どちらを採用すべきか自動判断できない から止まっているだけです。
実際に見るべきもの
コンフリクト時には典型的に次のような印が入ります。
<<<<<<< HEAD
現在のブランチ側の内容
=======
取り込みたい側の内容
>>>>>>> feature/login-validation
ここでやることは単純です。
- 現在側の意図を読む
- 相手側の意図を読む
- どちらを残すか、どう統合するか決める
大事なのは、印を消すことではなく、最終的に正しいコードを残すこと です。
実務での解消手順
1. どのファイルで衝突しているか確認する
2. その変更が何のためのものか把握する
3. 片方だけ採用するのか、両方を統合するのか決める
4. テストや動作確認を行う
5. 問題なければ解消済みとして進める
特に3番が重要です。機械的に「上を残す」「下を残す」ではなく、意図を読む必要があります。
実務でよくある失敗
- コンフリクト印だけ消して内容を読んでいない
- 片方の修正を丸ごと落としてしまう
- 解消後に動作確認しない
- なぜ衝突したかを振り返らない
コンフリクト解消は編集作業であると同時に、仕様理解やコード理解の確認作業でもあります。
強い人の考え方
| 危ない解消 | 強い解消 |
| とにかく印を消す | 変更意図を読んで統合する |
| 片方を機械的に採用 | 必要なら両方を組み合わせる |
| 解消後に確認しない | テストや画面確認まで行う |
コンフリクトに強い人は、Gitの操作が速い人というより、コードの意味を落ち着いて読める人です。
チェックポイント: コンフリクト解消のゴールは「印を消すこと」ではなく「正しい最終状態を作ること」です。
まとめ & 次のステップ
- コンフリクトはGitが自動判断できない状態
- 危ないのは発生そのものではなく、雑な解消
- 片方を選ぶか、両方を統合するかは意図で判断する
- 解消後は必ずテストや動作確認を行う
- コンフリクト対応はコード理解力が問われる場面でもある
次回はブランチ戦略の基本を扱います。 コンフリクトを減らし、チーム運用を安定させるには、そもそものブランチの切り方も重要です。
