Git Rebase 運用をおすすめしない理由
目次
概要
Git 運用ではしばしば Rebase 運用がいいという声を聞くことがあります。
個人的におすすめはしないですが、その理由を解説します。
Rebase 運用
Rebase 運用とは、main ブランチに対してマージするのではなく、main を rebase するという運用です。
メリットとしては変更履歴が綺麗に見えるところです。
feature_1, feature_2 と連続で繋がっているように見えるので、コミット履歴が綺麗に見えます。
それでもなぜおすすめしないか
本記事では rebase 運用をマージ運用と比較します。
以下、３つの理由でおすすめしないです。
force push で履歴が飛ぶ
rebase をすると、これまで実装した feature のコミットが変わってしまいます。
そうすると、コミット番号が全て変わります。
そのため git のレポジトリに push すると、違うブランチと認識するため、push ができなくなります。
これを解決する方法として force push がありますが、force push だと前後の位置も把握できなくなるため、いざどこまで作業したかがわからなくなります。
reset をした場合もリモートブランチを上書きします。
revert ができなくなる
マージ運用を使えばどの機能（ブランチ）がどこからどこまでかという記録をしているのに対して、rebase 運用だと機能と commit 範囲が把握できなくなることがあリます。
例えば特定の機能追加によってエラーが生じたとします。
マージ運用であれば commit を revert することを考えるかもしれません。
しかし、commit が他の commit に依存している可能性があります。
ここで「今度ブランチごと取ればいいじゃん」と思うかもしれません。
しかし、ここでまた問題が。。。
どこからどこまでが機能追加した部分だっけ？という問題が生じます。
また、ブランチ部分が把握できたとしても、後に追加したブランチのどれが現ブランチに依存しているか分からないです。
このようにコミットが綺麗になったとしても、機能単位で管理できなくなります。
(merge 運用だと、merge した箇所に対して、revert、reset すればいいだけです。)
conflict 解消が大量に生じる
rebase すると、同一の箇所に対して何度も conflict 解消が求められるケースがあります。
例えば、ファイル X に対して A という変更を加えた人、 B という変更を加えた人と、 C という変更を加え人がいるとします。
先に A を main にマージしたとします。
すると、rebase 時に B と C は conflict 解消をしなければなりません。
次に、B を main にマージしたとします。
すると、C は conflict を解消しなければなりません。
上記の例だと、C は２度の conflict を経験することになりました。Cは大変です。
上記３人を元に紹介しましたが、conflict の範囲が大きく、かつたくさんのチームメンバーが関わった時を想像してみてください。
たくさんの人たちが conflict 解消するはめになります。
もしマージ運用をしていたら、conflict 解消はマージごとに 1 回で済みます。
まとめ
本記事では、 rebase 運用をおすすめしないこととその理由を３つ挙げました。
少人数ならまだしも、大人数なら尚更避けるべきだと思います。
以上！
