プルリクエストのレビューでマージ先の確認が漏れていたため、間違ったブランチにマージしてしまうというのが起きたときに、めんどくさい作業を誰かがしないとなーと調べてたらGUIでサクッと修正できたのでそのメモ
要約
- 間違ったプルリクエストのrevertボタンからプルリクエストを作成しマージして戻す
- revertのプルリクエストから更にrevertボタンを押しプルリクエストを作成する
- このときにマージ先を本来マージしたい先にする
- マージする
起きたこと
中規模の開発案件で、それ用のマージ先のブランチを用意していたが、プルリクエストがデフォルトブランチのdevelopを向いたままだった上に初期だったためレビューの差分でも気づかず、マージまで行ってしまった。
行ったこと
feature/hogehoge から kaihatsuA ブランチにマージするはずが、developにマージしてしまった
まずは行った修正を戻す（revert）
間違ってマージしてしまったプルリクエストからrevertのプルリクエストを作成できる
GitHubを使いこなせていないため、GUI上でrevertできることすら知らなかった。
これはあまり考えずに、マージしてしまって良い。
戻した状況の確認
git初心者だともとに戻ったんだからこれで良いじゃん、と考えてしまう人もいるかもしれないが、revertは時を戻してくれるものではない。
あくまで「前のコードと同じものにする」というだけで、commit historyなどを見るとrevertが「追記」されていることがわかる。
つまり、前に戻ったのではない。むしろdevelopのほうがマージ元より新しい状態になっている。
そのため、再度developに向けてプルリクエストを送ると差分が出ない。
そのためマージ先にこの状態でfeature/hogehogeをkaihatsuAにマージしてしまうと、その取消コミットがdevelopにはあるぶん新しいためこのマージ先からdevelopにマージしようとしたときにその差分が出ない・もしくはコンフリクトで泣きを見ることになる。
revertしたものをrevertし、さらに向き先を本来のマージ先にする
先程revertのプルリクエストを出したが、さらにこれのrevertをボタンを押す。
こうすることで、feature/hogehogeから見ると、新しくしたコードを前のコードで書き直して（revert1）、さらにまた新しくしたコードで書き直した（revert2）がプルリクとして作成される
その上でマージ先を本来のマージ先に向けると行いたかった差分が出てくるはずである。
baseがdevelopに向いているのでkaihatsuAに向ける
コミット差分はこの通り
注：このときマージ元のデータはdevelopのデータ＋revertの差分なので、developにあってマージ先（kaihatsuA）にないコミットも含まれます。差分を正しく見たい場合は、マージ先にdevelopのデータを取り込めばよいです。
これをマージすれば、期待した差分が目的のブランチにマージされた形になります。