起こったこと
developブランチにマージしたプルリクエストたちを確認して、masterに上げる準備をしていた時のこと。
やったはずの作業がきれいさっぱり消え去っていました。ショック。
対処
わたしはよくGitでやらかすので分かるのですが、
Gitでやらかしているときはたいていコンフリクト解決の時にやらかしています。
1.再度コンフリクト解決の作業ができる状態にする
まずは、取り込まれていない作業のコミットを探してみます。ありました！
さらに、developブランチへのマージコミットを見てみると、
かなりハデにコンフリクトしてしまい、コンフリクト解決の作業をやったみたいです。
たぶんここでミスったのでしょう。もう一度コンフリクト解決させてほしい…。
とりあえず、CherryPickできないか試してみます。できません。
対象コミットにcheckoutして、新規ブランチを切ってプルリクエストを出してみます。Diffありません。
コンフリクト解決してマージしているので、
developと対象コミットにDiffがないことになってるってことなんでしょう。
文字にしてみると、そりゃそうなんですが、developブランチと対象コミットだけ見ていると、
「Diffあるよ！取り込んで欲しい！」という思いでいっぱいになります。
解決
何回か調べているのに毎回こんがらがってしまうのですが、
GitHubのFile Changedはマージ対象ブランチが「分岐点以降に積み上げた差分」。
参考：GitHubのプルリクエストの差分はどこと比較しているか？(git diffの".."と"..."の違い)
つまり、コミット同士を比較しているわけではないです。
今回、マージベース上はDiffがないってことなんですね。
感覚的にはコミット同士で比較しているつもりになっちゃいがちです。
対象コミットの親を変えてあげることで、マージベースでdiffが発生し、
プルリクエストを出したときにdevelopに対するDiffを認識してくれる状態にできました。
2.丁寧にコンフリクト解決する
ようやく、やらかしをなかったことにするスタートラインに立てました。
まずは、対象ブランチにdevelopブランチをマージして、コンフリクト箇所を明らかにします。
消え去って焦った内容が含まれているファイルをひとつ開いて見てみると、
コンフリクト行はその焦った内容の部分ではありませんでした。
ここで、急にハッと記憶がよみがえったのですが、
コンフリクトの量がえげつなさすぎて、全て片側の変更を適用しよう！で、
git checkout -theirs .を使ったのでした。
コンフリクト行はすべてdevelop側の変更で良い！でその判断だったのですが、
今回はそのファイルのコンフリクト行以外にも変更が加わっていたのがまずかった。
コンフリクト行以外の変更も採用されず、
結果的にdevelopブランチに取り込まれずじまいの変更になってしまっていました。
（しかもよく見たら、コンフリクト行もすべて両方の変更取り込むべきだった。ダメダメ。）
解決
横着しすぎず、VScodeで確認しながら解消します。
ただし、本当にえげつない量だったので、一ファイル一ファイルは現実的ではないです。
いくつかのファイルをとりあえず見ていってみると、
コンフリクト行に出ている変更自体、VScodeの一括置換でなされているものなので、
すべて同じ変更のようです。安心。
今回は両方の変更を取り込みたいので、VScode一括置換を活用して、
サーッとコンフリクトマーカーを消していきます。
置換結果をいくつか確認してみます。いい感じ。
編集したファイルをステージして、コンフリクト解消をgitに知らせます。
コミット・プッシュします。
プルリクエストのコンフリクトはもちろん解消されています。
file changedを見てみると…やりました！無事に作業が反映されているようです。
結論
コンフリクト解決をめんどくさがってはダメ。
かえってめんどくさいことになる（自戒）。
きちんと変更内容に向き合って解消させよう。