git rebaseとgit mergeは
両方とも「ブランチAの変更差分を、ブランチBに取り込む」コマンドである。
前提として、違いが良く分かっていなければ、基本的にmergeだけ使えば十分である。
そのうえで、コミットログを整理したいという欲が出てきたらrebaseを覚えると良い。
この記事の注意点
この記事では、筆者が業務で感じた主観が多く入っているため
rebaseを運用する場合の一例として見ていただきたい。
結論：rebaseしてはいけない状況
■rebaseしてはいけない状況
- プルリクエストのレビュー中
- mainブランチに変更を反映する時
■rebaseしてもよい状況
- まだ誰にもレビューされていない状態で、mainブランチの変更差分を取り込む
これらを詳しく説明するために、mergeとrebaseについての違いを説明していく。
mergeとrebaseの違い
mergeとrebaseの違いは簡単に言うと、過去のコミットIDが変わってしまうかどうかである。
- merge：今まで修正を加えたコミットIDは変わらない
- rebase：今まで修正を加えたコミットIDが変わる
開発中ブランチ「feature」に、mainブランチで発生した変更を取り込みたい
というケースを考えると、
mergeとrebaseの違いは以下のようになる。
見て分かる通りrebaseは、履歴を整理したいモチベーションで使うコマンドなので
その副作用としてコミットIDが変わってしまう、という点が最大の注意点である。
プルリクエストレビュー中にrebaseしてはいけない理由
GitHubには「以前途中までレビューしたところからの差分を確認する」という機能がある。
rebaseを利用してコミットIDが変わってしまうと、
以前ここまで見た、というコミットIDが消滅してしまうので
「前見たところからの差分が見たい」というレビューができなくなってしまう。
mainブランチに変更を反映する時
rebaseはコミットIDを書き換えることができるコマンドであるため
大切なmainブランチに対してはやらないほうが良い。
基本的にはmainブランチにはありのままの履歴を残しておくべきだからだ。
細かいことを言うと、ローカルでrebaseしたあとはforce pushが必要になる。
mainブランチに対してforce pushは危険なためやらない方が良い。
まとめ
- コミットログをきれいにしたいときにrebaseを使う
- レビュー中やmainブランチに対してはrebaseは使わない方が良い
