プルリクエストのレビューでマージ先の確認が漏れていたため、間違ったブランチにマージしてしまうというのが起きたときに、めんどくさい作業を誰かがしないとなーと調べてたらGUIでサクッと修正できたのでそのメモ

要約

起きたこと

中規模の開発案件で、それ用のマージ先のブランチを用意していたが、プルリクエストがデフォルトブランチのdevelopを向いたままだった上に初期だったためレビューの差分でも気づかず、マージまで行ってしまった。

feature/hogehoge から kaihatsuA ブランチにマージするはずが、developにマージしてしまった

間違ってマージしてしまったプルリクエストからrevertのプルリクエストを作成できる

GitHubを使いこなせていないため、GUI上でrevertできることすら知らなかった。

これはあまり考えずに、マージしてしまって良い。

git初心者だともとに戻ったんだからこれで良いじゃん、と考えてしまう人もいるかもしれないが、revertは時を戻してくれるものではない。
あくまで「前のコードと同じものにする」というだけで、commit historyなどを見るとrevertが「追記」されていることがわかる。

つまり、前に戻ったのではない。むしろdevelopのほうがマージ元より新しい状態になっている。
そのため、再度developに向けてプルリクエストを送ると差分が出ない。

そのためマージ先にこの状態でfeature/hogehogeをkaihatsuAにマージしてしまうと、その取消コミットがdevelopにはあるぶん新しいためこのマージ先からdevelopにマージしようとしたときにその差分が出ない・もしくはコンフリクトで泣きを見ることになる。

先程revertのプルリクエストを出したが、さらにこれのrevertをボタンを押す。
こうすることで、feature/hogehogeから見ると、新しくしたコードを前のコードで書き直して（revert1）、さらにまた新しくしたコードで書き直した（revert2）がプルリクとして作成される

その上でマージ先を本来のマージ先に向けると行いたかった差分が出てくるはずである。
baseがdevelopに向いているのでkaihatsuAに向ける

コミット差分はこの通り

注：このときマージ元のデータはdevelopのデータ＋revertの差分なので、developにあってマージ先（kaihatsuA）にないコミットも含まれます。差分を正しく見たい場合は、マージ先にdevelopのデータを取り込めばよいです。

これをマージすれば、期待した差分が目的のブランチにマージされた形になります。