なぜする必要があったか

プルリク発行⇒topicブランチにマージされた後、やっぱりおかしいのでは？とrevertされる
レビュアと話し合った結果、revertされた実装で合ってたという結論に至る
「ごめんね、元の実装でプルリク出し直しておいて」と言われ、元のブランチから再度プルリクを出そうとしたが...

変更あるって！と思いましたが、よく考えたら以下の図のようなことで取り込み済と判断されるのは当たり前でした。

commitID:abc123の作業はtopicブランチにマージ済なので「もう取り込んでるけど？」と言われていたのでした。

こうなったら取り消しの取り消しを行うしかない...。

実際の手順

topicブランチをpullして新しいブランチを作成し、revertコミットをrevertしました。

> git pull // 1.revertされた状態のtopicブランチに合わせる

> git checkout -b revert-revert // 2.新しいブランチを作成する

> git log // 3.revertのコミットIDを特定する

commit 456def.......... (origin/revert) // revertのコミットID
Author: レビュア
Date:   Thu Oct 14 05:16:11 2021 +0000

    Revert "イケてる実装 (pull request #001)"

commit 123abc..........
Author: shun.kondo
Date:   Thu Oct 14 05:14:41 2021 +0000

    イケてる実装

> git revert 456def // 4.revertのコミットIDを指定してrevert（取り消しの取り消し）

[<作業ブランチ名> <新しいコミットID>] Revert "Revert "イケてる実装 (pull request #001)""
 1 file changed, 1 deletion(-)

> git push --set-upstream origin revert-revert // 5.再度push!

無事に取り消しの取り消しを行い、元の実装の通りマージすることができました

他の方法もあるのか一応調べた

git resetでコミットのログごと消して-fオプションを付けて強制的にpushしてコミットログを綺麗にする...なんて方法もあるようです。

確かに「revert」「revertのrevert」とコミットログが並んでいるのはかっこよくはないですが、git resetはコミット自体がなかったことになるのでコンフリクトが起きやすいなどの弱点もあるようです。

なんにせよ作業の手順がそのまま残るのは悪いことではないと思うので、チーム開発ではgit revertを使用しておいた方が良い気がします。