先に要点
- どちらも ブランチを統合する操作ですが、履歴の残り方が違います。merge は分岐と合流をそのまま残し、rebase は履歴を直線に作り直します。
- git mergeは、2つのブランチを合流させる マージコミットを作ります(fast-forwardできる場合を除く)。履歴は正確だが、枝分かれが残る。
- git rebaseは、自分のコミットを 最新の先端へ積み直す。履歴は直線的で読みやすいが、コミットのハッシュは作り直される(=別物になる)。
- 黄金ルール: すでに push して共有したコミットは rebase しない。履歴が作り直されて他人の作業とズレ、事故になります。rebase は 手元の未共有コミットに使うのが基本です。
- ざっくり使い分けると、フィーチャーブランチを最新に追従・整える → rebase、完成した機能を共有ブランチへ取り込む → merge。チームの方針に合わせます。
git merge と git rebase、どっちで取り込めばいいの？ ── Git に慣れてくると必ずぶつかる分かれ道です。どちらも「別のブランチの変更を自分の作業に取り込む」操作ですが、できあがる履歴の形がまったく違います。ここを理解しないまま rebase を使うと、共有済みの履歴を壊して周りを巻き込む事故につながります。
この記事では、両者の違いを 統合という共通点 → それぞれの挙動 → 履歴の見え方 → 黄金ルール → 使い分けの順で整理します。挙動はGit公式ドキュメントの git-merge / git-rebase を確認しながらまとめています。取得と取り込みの関係が曖昧ならgit pullとgit fetchの違いも先に読むと土台が固まります。
前提: どちらも「ブランチを統合する」
まず共通点です。merge も rebase も、あるブランチの変更を別のブランチに取り込む(統合する)ための操作です。たとえば「main の最新を、自分の作業ブランチに取り込みたい」「完成した機能ブランチを main に入れたい」といった場面で、どちらを使うか選ぶことになります。
違うのは 取り込んだ結果、履歴がどう記録されるかです。ここを軸に見ていきます。
git merge は何をするか(合流を履歴に残す)
git merge は、2つのブランチを 合流させる操作です。両方のブランチにそれぞれコミットがある場合、Git は両者を1つにまとめた マージコミットを新しく作ります。このマージコミットは「ここで2つの流れが合流した」という記録として履歴に残ります。
一方、取り込む側にコミットが無く、相手が先に進んでいるだけなら、マージコミットを作らずに単に先端を進めるだけ(fast-forward)で済みます。
merge は既存のコミットを書き換えません(非破壊的)。分岐して合流した事実がそのまま残るため、履歴は正確ですが、開発が活発だとマージコミットが増えて枝分かれが複雑に見えることがあります。
git rebase は何をするか(履歴を積み直す)
git rebase は、自分のコミットを、別のブランチの最新の先端へ移動(積み直し)する操作です。「自分の作業を、いったん外して、新しい土台の上に順番に載せ直す」とイメージすると分かりやすいです。結果として、分岐していた履歴が一本の直線になり、マージコミットは作られません。
ただし重要な副作用があります。rebase はコミットを"作り直す"ため、元のコミットとは別のハッシュ(ID)を持つ新しいコミットに置き換わります。中身が同じでも、Git 的には別のコミットです。これが後述の黄金ルールにつながります。
git merge と git rebase の比較
| 観点 | git merge | git rebase |
|---|---|---|
| 履歴の形 | 分岐と合流が残る(非直線) | 直線的になる |
| マージコミット | 作られる(fast-forward時を除く) | 作られない |
| コミットのハッシュ | 変わらない | 作り直される(別物になる) |
| 履歴の正確さ | 分岐した事実がそのまま残る | 整うが、実際の経緯は消える |
| 読みやすさ | 枝分かれが増えると追いにくい | 一本で追いやすい |
| 共有済みブランチ | 安全 | 原則NG(黄金ルール) |
図で見る違い
黄金ルール: 公開済みコミットは rebase しない
rebase でいちばん大事なのはこれです。すでに push して他の人と共有したコミットは、rebase してはいけません。Git 公式ドキュメントも「自分のリポジトリの外に存在し、他人がそれを土台に作業している可能性のあるコミットは rebase するな」と明記しています。
理由は、rebase がコミットを作り直すからです。共有済みのコミットを rebase すると、あなたの履歴と、それを取り込んでいる同僚の履歴が食い違い、強制 push(--force)や、同僚側の面倒な修復が必要になる事故が起きます。
まだ push していない自分だけのコミットを整える・最新に追従させるのは安全。すでに共有した(push済みの)コミットには rebase を使わず、merge で取り込むのが原則です。
使い分け(実務の考え方)
よくある実務パターンは、「作業中は rebase で main に追従して手元を綺麗に保ち、完成したら merge で main に取り込む」という組み合わせです。どちらか一方だけが正解ではなく、チームの履歴ポリシー(直線的にするか、経緯を残すか)に合わせるのが基本です。
interactive rebase(コミットの整理)
rebase には、コミットを対話的に編集できる interactive rebase(git rebase -i)があります。これは統合というより 自分のコミットを綺麗にする用途で、レビュー前によく使います。
- squash / fixup ── 複数の細かいコミットを1つにまとめる。
- reword ── コミットメッセージを直す。
- reorder / drop ── 順番を入れ替える・不要なコミットを消す。
これも「コミットを作り直す」操作なので、push前の手元のコミットにだけ使うのが安全です。
よくある誤解・失敗
共有済みブランチを rebase
いちばんの事故。履歴が作り直されて同僚とズレる。push済みは merge、rebaseは手元だけ。
rebase なら履歴が消えて安全?
逆です。rebaseは履歴を書き換える破壊的操作。mergeの方が非破壊的で安全側です。
コンフリクトはrebaseだと出ない?
出ます。merge/rebaseどちらでも起き得ます。rebaseはコミットごとに順に解決する点が違います。
どちらかが常に正しい?
いいえ。チームの履歴ポリシー次第。直線を好むなら rebase 寄り、経緯重視なら merge 寄り。
git mergeとgit rebaseに関するよくある質問
git merge と git rebase の一番の違いは何ですか？
履歴の残り方です。merge は分岐と合流を マージコミットとして履歴に残します。rebase は自分のコミットを最新の先端へ 積み直して履歴を直線的にしますが、その際コミットは作り直されて別のハッシュになります。
どちらを使えばいいですか？
目安として、push前のフィーチャーブランチを最新に追従・整えるなら rebase、完成した機能を共有ブランチ(main)へ取り込むなら mergeです。迷ったら、非破壊的で安全な merge を選べば大きな事故にはなりません。
なぜ共有済みのコミットを rebase してはいけないのですか？
rebase はコミットを作り直すため、共有済み(push済み)のコミットを rebase すると、あなたの履歴とそれを取り込んだ同僚の履歴が食い違います。結果として強制 push や同僚側の修復が必要になり、事故になります。だから rebase は手元の未共有コミットに使うのが原則です。
git pull --rebase は merge と何が違いますか？
git pull はリモートを取り込むときに 既定では mergeで統合しますが、--rebase を付けると rebase で統合します。手元のコミットをリモートの最新の上に載せ直すため、履歴が直線的になります。詳しくはgit pullとgit fetchの違いで扱っています。
rebase でコンフリクトが出たらどうしますか？
rebase は コミットを1つずつ順に載せ直すため、コンフリクトもコミット単位で出ます。該当ファイルを直して git add し、git rebase --continue で次へ進みます。途中でやめたい場合は git rebase --abort で元に戻せます。
squash はどうやりますか？
git rebase -i(interactive rebase)で、まとめたいコミットを squash または fixup に指定します。複数の細かいコミットを1つにまとめられ、レビュー前の整理に便利です。これも push 前の手元のコミットに使います。
まとめ
git merge と git rebase の違いは、統合した結果の履歴の形に集約されます。merge は分岐と合流をマージコミットとして残す非破壊的な統合、rebase は自分のコミットを最新の先端へ積み直して履歴を直線的にする(コミットは作り直される)統合です。最重要は黄金ルール、共有済み(push済み)のコミットは rebase しないこと。使い分けは「push前の手元を整えるなら rebase、共有ブランチへ取り込むなら merge」を出発点に、チームの履歴ポリシーに合わせれば迷いません。関連して、複製の話はGitのforkとcloneの違いも参考になります。
参考リンク
- Git 公式: git-merge ドキュメント
- Git 公式: git-rebase ドキュメント
- Git 公式(Book): Git のブランチ機能 - リベース
- 用語集: rebase / Git