featureブランチでGitコンフリクトが4回起きてから撤退した記録：AIとのGit運用の実際

2026年6月22日

Shiori

この記事について

Gitのfeatureブランチで作業を続けているうちに、コンフリクトが4回連続して発生しました。AIと一緒に解決を試みましたが、最終的にブランチを破棄して最初からやり直す判断をしました。その経緯と、そこから得た教訓を記録します。

技術的な背景を持たない方のために、Gitコンフリクトを簡単に説明します。

Gitは、ファイルの変更履歴を記録するツールです。複数の変更を並行して進めることができますが、2つの異なる変更が同じファイルの同じ箇所を書き換えたとき、「どちらの変更が正しいか」をGitが判断できなくなります。この状態がコンフリクト（衝突）です。

たとえるなら、2人が同じ文書の同じ段落を、別々に編集してしまったような状況です。一方は「第3段落を削除した版」、もう一方は「第3段落に追記した版」があるとき、最終的にどちらの版を採用するかを人間が判断しなければなりません。

あるとき、サイトのナビゲーション構造を大きく変更する作業をfeatureブランチで進めていました。変更の規模が大きかったため、作業を複数日に分けて進めていました。

最初のコンフリクトは、mainブランチで行われた別の修正が、featureブランチの変更と同じファイルに触れていたことで発生しました。AIと一緒に確認して、どちらの変更を残すかを判断し、解決しました。

2回目のコンフリクトは、その解決作業中にAIが別のファイルを修正したことで発生しました。解決しようとした操作が、新しい衝突を生んでしまいました。

3回目・4回目も同様の流れでした。解決のために加えた修正が新しいコンフリクトを引き起こし、解決のたびに別の問題が発生する状態になりました。

AIはコンフリクトの解決を手伝ってくれましたが、AIが「解決した」と判断した変更が、実際には別の箇所で新しい問題を引き起こすことがありました。

AIはファイルの内容を確認しながら変更を提案しますが、すべてのファイル間の依存関係を把握した上で操作するわけではありません。1つのコンフリクトを解決しながら、別のファイルの整合性を壊してしまう、という状況が重なりました。

4回目のコンフリクトが発生したとき、このbranchを続けることを止める判断をしました。

理由は3つです。

コンフリクトの連鎖が収まる見込みが立たなかった：解決するたびに新しいコンフリクトが発生する状態は、featureブランチがmainブランチから長期間離れすぎたことを示していました。
どの変更が正しいか判断するコストが上がっていた：最初は「このファイルのこの行」という単位で判断できていたのが、変更の積み重ねで「どのファイルがどの状態であるべきか」がわかりにくくなっていました。
ゼロから始めた方が速いと判断した：変更の内容は理解できていたので、最初からやり直すほうが総時間は短くなると判断しました。

ブランチを破棄して、mainブランチから新しいfeatureブランチを作り直し、変更を小さな単位で加えながら進めました。

ブランチは長く持ちすぎない。

featureブランチをmainブランチから長期間分岐させ続けると、その間に行われたmainブランチへの変更との距離が広がります。距離が広がるほど、後でまとめて解決しなければならないコンフリクトが増えます。

AIと一緒に作業する場合も同様です。AIは変更を加えるのが早いため、短時間で多くのファイルに手が入ります。それだけ早く、他の変更との衝突が起きる条件が整います。

変更の単位を小さくする、featureブランチの寿命を短くする、定期的にmainブランチの変更を取り込む、という3点が今回の反省から得た実践的な対策です。