このブログの運用でもGitを使い始めましたが、複数人での案件ではもっと頻繁にコンフリクト(競合)に遭遇します。今回は、実務でよく出くわすコンフリクトのパターンと、解消するときに意識していることをまとめます。
そもそもコンフリクトはなぜ起きるか
コンフリクトは、同じファイルの同じ箇所を、異なるブランチで別々に変更してしまったときに発生します。Gitは自動的にマージできる変更(違う箇所の変更同士)は勝手に統合してくれますが、同じ行を書き換えるような変更は「どちらを正としていいか判断できない」ため、人間に判断を委ねてきます。コンフリクト自体は異常事態ではなく、複数人・複数ブランチで開発している以上は自然に起きるものだと捉えるようにしています。
よくあるパターン1: SCSSの同じセレクタを別々に触った
デザイン修正の案件でよくあるのが、同じコンポーネントのSCSSファイルを、自分と別の担当者が同時に触っているケースです。例えばボタンの余白を自分が調整していて、同じタイミングで別の人が色を調整していると、同じ行または近い行が競合します。この場合は、どちらか一方を機械的に採用するのではなく、両方の変更意図を確認した上で、両方を反映した状態に手動で書き直すようにしています。片方を切り捨てると、せっかくの修正がなかったことになってしまいます。
よくあるパターン2: 同じファイルへのimport文の追加
新しいコンポーネントのSCSSファイルを追加する際、エントリーポイント(style.scssなど)に@use文を1行追加する、という作業がよく発生します。複数人が同時に新しいコンポーネントを追加していると、同じ行の近くに別々の@use文を追加しようとして競合することがあります。この手のコンフリクトは実質的に「両方追加すればいい」だけのケースがほとんどなので、落ち着いて両方の行を残す形で解消しています。焦って片方だけ採用してしまうと、コンパイルエラーや意図しないスタイル漏れにつながるので注意が必要です。
よくあるパターン3: 生成ファイルのコンフリクト
SCSSをコンパイルしたstyle.cssのような、自動生成されるファイルもコンフリクトの原因になりがちです。ソースのSCSSは競合していなくても、コンパイル後のCSSファイルは実質的に全行が書き換わるため、機械的な差分としては大きな競合として扱われることがあります。この場合は、生成ファイル側の中身を手動でマージしようとせず、コンフリクトが解消したソースファイルから改めてビルドし直し、生成ファイルはビルド結果でまるごと置き換える、という対応にしています。生成物を人力でマージしようとするのは大抵の場合、時間の無駄になります。
コンフリクト解消の基本的な流れ
- コンフリクトが起きたファイルを開き、
<<<<<<<から>>>>>>>までのマーカーを探す - 自分の変更(HEAD側)と相手の変更(マージ元側)の両方の意図を確認する
- 両方の意図を汲んだ最終形をその場で書き直し、マーカーごと削除する
- 変更後、実際にビルド・表示確認をして問題ないことを確認してからコミットする
エディタの「両方の変更を受け入れる」といった自動解消ボタンに頼りきらず、必ず最後に人間の目で「この状態で意味が通っているか」を確認するようにしています。特にCSSは、両方をただ並べただけだと意図せず片方が上書きしてしまうこともあるので、機械的な解消だけでは不十分なことが多いです。
解消後は必ず動作確認してからコミットする
コンフリクトマーカーを削除できた時点で安心してすぐコミットしてしまいたくなりますが、必ずビルド・表示確認を挟むようにしています。マーカーの削除自体はうまくいっていても、両者の変更を組み合わせた結果、意図しない見た目やロジックのバグが生まれていることがあるためです。コンフリクト解消は「文字列としてきれいに統合できたか」ではなく「機能として正しく動くか」がゴールなので、最後の確認を省略しないことが大切だと感じています。
コンフリクトを未然に減らす工夫
コンフリクト自体はゼロにはできませんが、発生頻度を下げる工夫はできます。作業を始める前にこまめにgit pullして最新の状態を取り込んでおく、大きな変更は早めに小さくコミット・共有しておく、といった基本的な習慣が結局は一番効きます。コンフリクトが起きてから慌てて解消するより、そもそも差分を小さく保っておく方が、解消作業自体もずっと楽になります。
ブランチを長期間放置せず、こまめに本流に統合していくという進め方は、コンフリクト対策としてだけでなく、そもそもの作業の見通しの良さにもつながります。結局のところ、コンフリクトの解消力そのものより、コンフリクトが起きにくい進め方を身につけることの方が、長い目で見ると効いてくると感じています。
個人開発でコンフリクトとほぼ無縁だった時期を経て、改めて実務のGit運用を振り返ると、当たり前だと思っていた習慣ほど、実は事故を防ぐための工夫だったんだと気づかされます。
まとめ
コンフリクトは、Gitを使う以上避けて通れないものですが、「なぜ起きたか」を理解していれば、慌てず落ち着いて対応できます。個人のブログ運営ではまだ自分ひとりの作業なのでコンフリクトはほぼ起きませんが、案件で身につけたこの感覚は、今後複数人での運用に発展したときにもそのまま活きると思っています。
