PRを分割したかっただけなのに、コンフリ地獄になった話

はじめに

「PRを分割しようとしてcherry-pickしたらコンフリクトで壊れました」こんな感じの相談で面談予約が入っていました。

何が起きたか確認していくと、Gitでよくありそうなハマりポイントが詰まっていたので 何が起きていたのか・どう解決するのがよいかを整理してみます。

相談内容（要約）

状況はこんな感じでした👇

• 個人開発

• mainからブランチを切って開発

• PRを作成

しかし問題発生！！！ 本来別PRにすべき変更もまとめて入れてしまった🤦‍♀️

やったと聞いたこと

PRを分割するために、新たにブランチを切って

git cherry-pick <コミットハッシュ>

このように入れてしまった余計なコミットに対して別ブランチに移動し、その後さらに追加の修正を加えた。

さらに

• Prismaのmigration削除

• .gitignore変更

などの処理をしたとこのこと！

起きた問題

GitHub上で

This branch has conflicts that must be resolved

さらに

• 型エラーが出る

• ファイルが足りない

• コンフリクトが解消できない

まぁ当然に困惑しますよね😱

何が起きていたのか

結論から言うと 履歴が分岐した状態で同じ領域を触っていた ことが原因でコンフリが発生した主な原因です。

ポイント① cherry-pickはコピー

元のコミット: D
cherry-pick後: D'

見た目は同じでも別コミットです！

同じ差分を別の差分としてコミットコピーしているだけなんです。

cherry-pickは私は全く使わず「コミットを移動できるよ〜」と聞いたことがあるくらいですが、当然に使う現場もあると聞きます👀

ポイント② Gitは履歴で判断する

Gitは「同じ内容かどうかは知らない。履歴が違えば別変更」と判断して、同じ場所をいじっていたら、どんな差分か関係ない、コンフリ！となります。

そのため

• D（元の変更）

• D'（コピー）

両方とも別の変更として扱われた結果コンフリが発生🔥という流れだったようですね、！

ポイント③ 悪化させた要因

相談内容で

• migrations削除（構造変更）

• .gitignore変更

• 追加コミット

依存関係が増えた状態で、さらに元PRをマージしないままに修正を加えてcherry-pickした方のPRを先にマージしてしまったようです。

なので元のPRがコンフリしたというわけですね！！！

解決方法

今回のケースでの対処方法としておすすめなのは履歴を一度整理してから積み直すことかなと思います。

手順

① 追加した変更を退避

git checkout 元ブランチ
git checkout -b extra-work

② 元ブランチをマージすべきだったLGTM時点に戻す

git checkout 元ブランチ
git reset --hard <LGTMコミット>
git push -f

自分以外の人も触っているプロジェクトなら最後のpush -fではなく

git push --force-with-lease

にします。自分以外の変更が入ってたら弾いてくれるので安全にpushを強制できます。

③ PRをマージ

resetで不要な変更がない状態でマージして本来あるべきだった処理を成立させるのを先にやりたいですね。

一回コピーブランチ作ってるので変更が消える心配はしなくて大丈夫です。

④ 続きは別ブランチで再開

git checkout main
git pull
git checkout extra-work
git rebase main

なぜこの方法がいいのか

履歴のズレをリセットできるからです。

rebaseを使う理由

• merge は別々の歴史を無理やり合流させて「混ぜました！」という新しい結び目を作る(コミットがそのままになりますよね)

• rebase は古い土台をよしなに無視して最新のmainに植え替え、「今ここで初めてブランチ切りました」みたいな顔します

• 最大の差は、rebaseならcherry-pickで重複した中身をGitが空気を読んで自動でスキップし、履歴を一本道に掃除してくれること

歴史の改ざんができるのが rebase の強みですね！チーム開発では履歴を残す必要がある場合もあるので安易にやってはいけないと思いますが！！！

rebase は最新のmainの上にコミットを積み直す操作であり、その過程で不要な差分や重複に気づきやすくなりますが、自動で全部がいい感じになるわけではないのでチーム開発ではrebaseではなくmergeをするのが原則です。

学び

① cherry-pickは万能ではない

複数コミットある場合は順番にやらないとおかしいです。

• そのコミット単体で完結している

• 依存がない

といった使える条件もあります

② PRは最初から分ける

後から分割はコストが高いです、、！
マージのし忘れには御用心🚀

③ resetは怖くない

ただしバックアップは取ることですね、、バックアップを使えばミスってもなんとかなる、、！

git checkout -b backup

まとめ

今回の困惑するコンフリの原因は

• cherry-pickで履歴が分岐した

• 追加変更で依存増加した

• 構造を変更した

複合的な問題があったと思います。

おわりに

いや〜gitって怖いですね。。。
コンフリとかしたらヒィエエだるぅぅぅってなります。

マージする順番も大事なのでmainの状態とPRの履歴の状態はどうなってるかよく確認しながら進めたいものです！
mainに直pushは他人の履歴を壊したり、デプロイサイクルを乱したりするからダメですよ🙅‍♀️

オリアプは誰にも迷惑かけないところなのでこの段階でたくさん失敗して頑張りましょう🙌🏻