Github には revert ボタンがあるのでカジュアルに使いがちだけど、 compare で差分 0 になるのなんでなんだろう、と思っていたら同じような悩みの人はいるのだった。

結局のところ、 revert を指定するコミットで含まれるファイルに、より後のコミットで変更があれば差分が出てくるという理解でよさそう。

revert は打ち消しというより無効化

man を読んでもいまいちわからねえし、日本語ドキュメントでは打ち消しと表現されるけど、個人的には revert は無効化であると思う。

指定したコミットに含まれる変更内容をすべて無効とする。なので、同じ内容の変更をもう一度 push しても、 Github などの画面上で差分が出ないという理解だ。

feature ブランチを作らず (main|staging|develop|master) に直接 push してしまった！

revert したいモチベーション、おそらく初期に罹患するのはこのあたりだと思う。

で、とりあえず Github 上から revert して PR 出して merge すると、該当ブランチの HEAD から消えるので「よかったよかった」となり、再度 feature ブランチを作成して、同様の修正を push する。そうすると差分が出ずに「ナ、ナンデ！？」となる。

ここで取るべきは、 revert の revert と言われるやつである。まあ直感的に分かりづらいのだけど、 revert した内容とまったく同一の内容を復活させるには revert しかない、と思っておけば良い。

なのでこの場合、feature ブランチに push すべきなのは、個々のファイルではなく revert したコミットを再度 revert する、というコミットだ。

revert というか歴史修正系でよくあるのが、 conflict するのが嫌でやりたくない、というやつ。わかるんだけどそれはお前の罪なのでやれ。どうすれば良いかわかんなかったら、修正内容をまとめて git おじさんかおばさんに頭を下げるしか無い。

万能の解決方法はないのだ。

いや僕もこのあたりは「git は (SVN など先発とは違って) 頭がいい」という説明をよくされたので、いわゆる merge の際の挙動がすごいのだと思っていた。実際はそうではない。そうではないのだ……！

つらい。

よくわからなくなってきた。備忘録みたいな記事のつもりだったのに。