mergeとrebase は結局何が違うのか

はじめに

ようやくGitを使い慣れてきた最近ですが、git rebaseの使い方だけが分からないままでした。どちらも主にブランチ統合に使われるコマンドのようですが、普段はgit mergeしか使わないので、git rebaseはブランチ統合よりもコメントメッセージを修正するために使用していました。

会社の運用方針的に今後も使うことは無いと思いますが、調べた事をまとめておきたいと思います。使わないならなおさら忘れると思いますし。

mergeとrebase の違い

mergetとrebase の違いについてそれぞれの特徴を見ることで理解していきましょう。

コミットログの違い

先にmergeについて整理してみます。

仮に自分がdevブランチで開発を勧めていたとします。devブランチでの変更をmasterブランチに反映したい場合、mergeを行います。

mergeを実施すると下図の様に新しくmergeをしたというFコミットが発生します。

※ちなみに本当ならdevブランチをmasterブランチにmergeする前に、masterブランチのEコミットをdevブランチに取り込んでからmergeするべきです。理由はmasterブランチのEコミットと、devブランチのC・Dコミットで同じファイルを編集していた場合にコンフリクトが発生するかもしれないからです。

リベースの場合はどうでしょうか。

devブランチに移動して
$(dev) git rebase master
もしくは
$(dev) git rebase master dev

devブランチの派生コミットがBからEに変わっています。またこの時、元々のコミット内容も変化しています。

リベースはコミットの内容が変化してしまうので、注意が必要ですがコミットログが非常に綺麗に保たれます。

コンフリクト時の対応

コンフリクト時の対応が少し異なります。

• mergeの場合
  • コンフリクト解消→addしてcommit
• rebase
  • コンフリクト解消→rebase --continue
  • リベースしてもソースコードに変化がない場合はrebase --skip

rebaseの他の使い方

リベースにはブランチを統合する以外にも機能があります。例えばコミットの内容を変更する場合などです。むしろそのためによく使います。

例えばコミットメッセージを変えたいという時が無いでしょうか。hoge.txtを作成したのに、「moge.txtを作成しました」みたいなコメントでコミットをした場合、コメントだけを変更出来たらスマートですよね。

$ git rebase -i HEAD~[戻りたいコミット数]

上記のコマンドを実行するとインタラクティブなエディタ画面が表示されます。pickをrewordに書き換えて保存すると、次の画面がロードされます。そこでコメントを書き換えて保存すると無事コミットメッセージだけが修正されます。

終わりに

基本的にローカル作業時にrebaseを用いて、本番環境への反映にはmergeを使用する運用が多いみたいです。それにしてもgitはやはり奥が深いです。