Gitのrebaseとは｜mergeとの違いを基礎から解説

Gitを学び始めると、必ず出てくるのが「merge」と「rebase」です。
どちらもブランチを統合するための機能ですが、仕組みと履歴の残り方が大きく異なります。

本記事では、Gitのrebaseの基本からmergeとの違い、使い分けの考え方までを整理します。
基礎を正しく理解し、履歴を意図通りに管理できる状態を目指します。

rebaseとは何か

■ rebaseの基本的な考え方

rebaseとは、あるブランチの基点（ベース）を別のブランチの先頭に付け替える操作です。

たとえば、mainブランチから分岐したfeatureブランチがあるとします。
その後mainが進んだ場合、featureを最新のmainに追従させる方法は2つあります。

• mergeする
• rebaseする

rebaseを実行すると、featureのコミットが最新のmainの後ろに積み直される形になります。

つまり、

「履歴を一本の直線に整える」操作がrebaseです。

mergeとの違い

■ mergeの仕組み

mergeは、2つのブランチを統合する際にマージコミットを作成する方法です。

詳しくは
👉 Gitのmergeとは｜仕組みと使いどころを基礎から解説
で解説しています。

mergeの特徴は以下です。

• 履歴をそのまま保持する
• 分岐と統合の流れが残る
• マージコミットが作られる

履歴は次のようなイメージになります。

A---B---C main
     \  
      D---E feature
           \
            M (merge commit)

■ rebaseの仕組み

rebaseの場合は、featureのコミットをmainの最新地点に「移動」させます。

A---B---C---D'---E' main

DとEは「再適用」されるため、コミットIDは変わります。

mergeとrebaseの違いまとめ

rebaseのメリット

① 履歴がきれいになる

履歴が一直線になるため、git logが読みやすくなります。
小規模開発や個人開発では特に扱いやすい方法です。

② 不要なマージコミットが増えない

細かい作業ブランチを統合するたびにマージコミットが増えるのを防げます。

rebaseのデメリット

① コミットIDが変わる

rebaseは「履歴を書き換える」操作です。
そのため、すでに共有されたブランチに対してrebaseを行うと、履歴の整合性が崩れる可能性があります。

② チーム開発では慎重に扱う必要がある

基本原則として、

共有済みブランチにはrebaseしない

というルールが推奨されます。

ブランチ運用の基礎については
👉 Gitのブランチとは｜安全に作業を分ける仕組みを解説
もあわせて確認すると理解が深まります。

rebaseの基本コマンド

git checkout feature
git rebase main

これで、featureブランチの変更がmainの最新状態の上に積み直されます。

コンフリクトが起きた場合

rebase中に競合が発生した場合は、

git add .
git rebase --continue

で続行します。

中断する場合は、

git rebase --abort

で元に戻せます。

コンフリクトの基本については
👉 Gitでコンフリクトが起きたときの対処法
を参照してください。

rebaseとmergeはどちらを使うべきか

■ 個人開発の場合

• 履歴をきれいに保ちたい場合 → rebase
• 操作を単純に保ちたい場合 → merge

■ チーム開発の場合

• 共有ブランチ → merge推奨
• ローカル作業整理 → rebase可

運用ルールを決めて統一することが最も重要です。

Gitの基本的な仕組みを理解していないと混乱しやすいため、
👉 Gitの基本と仕組みを理解する
もあわせて読んでおくと安心です。

まとめ

rebaseとは、ブランチの基点を付け替え、履歴を直線的に整える操作です。
mergeとの違いは「履歴を残すか」「書き換えるか」にあります。

• 履歴を正確に残したい → merge
• 履歴を整理したい → rebase

どちらが正解というものではなく、
目的と運用ルールに応じて選択することが重要です。

関連記事

• Gitのmergeとは｜仕組みと使いどころを基礎から解説
• Gitのブランチとは｜安全に作業を分ける仕組みを解説
• Gitの基本と仕組みを理解する
• Gitでコンフリクトが起きたときの対処法