git : rebase での Current と Incoming

「git rebaseなんてそうそう使うものではない」と思っていたのだが、GitHub で Pull Request を出す際に「最新のメインブランチで出し直して」みたいな状況があってそうもいっていられなくなった。

すんなり rebase できるときもあればコンフリクトすることもある。
コンフリクトの解消がどうも苦手なので、ちゃんとしておこう。

コンフリクトしたときには「正しく修正する」のが基本ではあるが、なかなか難しいと思うのだよ。
そういうときは過去すぎて忘れてることも多いしね。

 

今回のテーマは「Current」と「Incoming」はどっちがどっちなのだ？である。

---

Visual Studio Code で解消しているので、その視点で見ていく。

Source Control バーで「!」マークがついているのがコンフリクトしているファイルたちである。
コンテキストメニューはこうなっている。

まあ、コンテキストメニューは All しかないが、ファイルの方ではコンフリクトした箇所それぞれに Current と Incoming が見えている。上側が Current で下側が Incoming になっていると思う。

記憶に残っていればなんとかなるのだが、package.json とかだとバージョンだけ違うけど変更するほどでもない、みたいなこともある。package-lock.json なんかは手動でマージが面倒だから作り直すこともありそうだし、go.sum なんかは私にはちょっと無理だ。

 

ブランチA を自分が編集中で、ブランチB を rebase に選んだという状況だということにしよう。つまりブランチB の最新 commit に差し替えようとしてコンフリクトした、ということだ。

ブランチB にブランチA を継ぎ足そうとしているので、ブランチB の最新 commit に対してブランチA の commit を 1つずつ順番に確認していく。
つまり、今(ブランチB) に対してブランチA のこの commit が不一致の原因なのだけどどうする？という問いかけなので、

• Current : ブランチB
• Incoming : ブランチA の特定 commit

ということになる。

「私の修正は無視していいですわ」という場合は Current を選べばよいし、commit として無視して良いなら --skip する。
もし自分の修正を反映することになるなら、その commit は新たな commit としてブランチB に接ぎ木される。すんなり rebase が成功するときはこの場合だな。