【図解で比較】Git merge vs rebase — 履歴統合の違いを徹底解説

いい質問だね。どちらもブランチの変更を取り込む操作だけど、コミット履歴の残り方がまったく違うんだよ。mergeは「合流した」という記録を残すけど、rebaseは「最初からここで作業してました」という形に履歴を書き換えるんだ。

mergeは既存のコミットを一切変更しないから、安全性は高いよ。featureブランチをmainにmergeすると、両方の履歴を合流させる「マージコミット」が1つ作られるんだ。ただ、ブランチが多いプロジェクトだと履歴がスパゲッティみたいに入り組んでしまうのがデメリットだね。

そのとおり。rebaseはfeatureブランチのコミットを、mainブランチの先端に「載せ替える」イメージだよ。結果的に一直線の履歴になるから、git logがとても読みやすくなるんだ。ただし、コミットのハッシュが全部変わるから注意が必要だね。

すでにリモートにpushしたブランチをrebaseすると、他のメンバーが持ってるコミットと食い違ってしまうんだよ。だから「まだpushしていないローカルのコミットだけrebaseする」というのが鉄則だね。pushした後にrebaseしてforce pushすると、チームメンバーの作業が壊れる可能性があるんだ。

よくあるパターンは「mainへの統合はmerge、ローカルの整理はrebase」だよ。featureブランチで作業中にmainが進んだら、git rebase mainで自分のブランチを最新に追従させる。最終的にmainに入れるときはmerge（またはプルリクエスト）を使う。これが一番トラブルが少ないやり方だね。

mergeだとコンフリクトの解決は1回で済むんだけど、rebaseだとコミットを1つずつ載せ替えるから、コミットごとにコンフリクトが発生する可能性があるよ。5つコミットがあれば最大5回解決が必要になることもあるんだ。だからコミットが多いときはmergeのほうが楽な場合もあるね。

git rebase -i を使うと、コミットの順番を入れ替えたり、複数のコミットを1つにまとめたり（squash）、コミットメッセージを書き換えたりできるんだよ。プルリクエストを出す前に「WIP」や「typo修正」みたいな細かいコミットを整理するのに最適だね。

実は、GitHubのプルリクエストには「Squash and merge」と「Rebase and merge」というオプションがあって、これを使えばブランチ上のコミットをmain側で自動的に整理できるんだよ。Linuxカーネルの開発ではrebaseを積極的に使って履歴を美しく保つ文化があるけど、大規模チームではmerge commitを残して「いつ・誰が・どのPRで入れたか」を追跡しやすくする方針のところも多いんだ。

まさにそう。もう一つ上級者向けの話をすると、git rerereという機能を有効にしておくと、一度解決したコンフリクトのパターンをGitが記憶してくれて、rebase中に同じコンフリクトが出たら自動で解決してくれるんだよ。rebaseを多用するチームではgit config rerere.enabled trueを設定しておくと、かなり作業が楽になるね。

Gitは「履歴をどう管理するか」に対する哲学が詰まったツールだからね。まずはローカルでrebase、リモートへはmergeという基本を押さえて、慣れてきたらインタラクティブrebaseやrerereを試してみるといいよ。大事なのは「チームで方針を揃える」ことだね。