git merge と git rebase の違いを徹底比較！どちらを使うべきか

2025年8月30日

Git を使った開発では、複数のブランチを統合する場面が頻繁に発生します。その際に「merge を使うべきか、rebase を使うべきか」という選択に迷う開発者は多いのではないでしょうか。

この記事では、git merge と git rebase の技術的な違いを詳しく比較し、どちらを選択すべきかの判断基準をお伝えします。実際のコマンド例や図解を交えながら、初心者の方にもわかりやすく解説していきますので、ぜひ最後までお読みください。

背景

Git でのブランチ統合の重要性

現代のソフトウェア開発において、Git のブランチ機能は欠かせない存在となっています。機能開発やバグ修正を独立したブランチで行うことで、メインブランチの安定性を保ちながら並行開発を実現できます。

しかし、開発が完了したブランチをメインブランチに統合する際に、どの方法を選ぶかによってプロジェクトの管理性や可読性に大きな影響を与えることになります。適切な統合方法を選択することで、チーム全体の開発効率を向上させることができるのです。

merge と rebase が生まれた理由

Git には、ブランチを統合するための主要な方法として merge と rebase が用意されています。これらが存在する理由は、異なる開発シナリオに対応するためです。

merge は、ブランチの統合履歴を明確に残したい場合に適しており、「いつ、どのような変更が統合されたか」を後から追跡しやすくする目的があります。一方、rebase は、より綺麗で線形なコミット履歴を維持したい場合に使用され、プロジェクトの歴史をシンプルに保つことを重視しています。

以下の図は、Git におけるブランチ統合の基本的な考え方を示しています。

mermaidflowchart LR
  main[main ブランチ] -->|分岐| feature[feature ブランチ]
  feature -->|開発完了| integration{統合方法の選択}
  integration -->|merge| merge_result[マージコミット付き統合]
  integration -->|rebase| rebase_result[線形履歴での統合]
  merge_result --> final_main[統合後の main ブランチ]
  rebase_result --> final_main

図で示すように、同じ統合でも選択する方法によって最終的なコミット履歴の形が変わることがわかります。

git merge の基本概念

merge の仕組みと動作原理

git merge は、2 つのブランチの変更を統合し、新しいマージコミットを作成する方法です。元のブランチの履歴を保持しながら、統合した事実を記録に残します。

merge の基本的な動作は以下の通りです：

typescript// merge の基本コマンド
git checkout main
git merge feature-branch

このコマンドを実行すると、Git は以下の処理を行います。

まず、両ブランチの共通の祖先コミットを見つけ出します。次に、それぞれのブランチで行われた変更を比較し、自動的に統合できる部分は統合します。

bash# merge 実行時の内部処理例
# 1. 共通祖先の特定
git merge-base main feature-branch

# 2. 3-way merge の実行
git merge-tree $(git merge-base main feature-branch) main feature-branch

コンフリクトが発生した場合は、手動での解決が必要になります。

merge によって作られるマージコミット

merge の特徴的な点は、統合時にマージコミットという特別なコミットが作成されることです。マージコミットは 2 つの親コミットを持ち、「どのブランチがいつ統合されたか」という情報を保持します。

bash# マージコミットの確認
git log --oneline --graph
* a1b2c3d (HEAD -> main) Merge branch 'feature-branch'
|\
| * e4f5g6h (feature-branch) Add new feature
| * h7i8j9k Fix bug in feature
|/
* k9l0m1n Initial commit

このマージコミットにより、プロジェクトの歴史において「いつ機能が追加されたか」を明確に把握することができます。

merge のメリット・デメリット

merge を使用することで得られる利点と、注意すべき点を整理してみましょう。

メリット：

履歴の保持: 元のブランチの開発履歴が完全に保存されます
安全性: 既存のコミットを変更しないため、履歴の改変リスクがありません
追跡性: マージコミットにより、統合のタイミングが明確になります

デメリット：

履歴の複雑化: マージコミットが増えると、履歴グラフが複雑になります
ノイズの増加: 頻繁なマージにより、重要なコミットが埋もれる可能性があります

以下の表は、merge の特性をまとめたものです：

項目	特徴	影響
1	コミット履歴の保持	元のブランチの開発過程が完全に記録される
2	マージコミットの作成	統合の事実が明確に記録される
3	安全性	既存コミットが変更されない

git rebase の基本概念

rebase の仕組みと動作原理

git rebase は、ブランチのベース（基点）を変更し、コミットを新しいベースの上に「再適用」する機能です。その結果、まるで最初から新しいベースから開発を始めたかのような線形な履歴を作成します。

rebase の動作プロセスを段階的に見ていきましょう。

typescript// rebase の基本コマンド
git checkout feature-branch
git rebase main

rebase 実行時の内部処理は以下のように進行します：

bash# rebase の内部処理ステップ
# 1. 共通祖先から現在のブランチまでのコミットを一時保存
git log --oneline main..feature-branch

# 2. 現在のブランチを対象ブランチの最新コミットに移動
git reset --hard main

# 3. 保存したコミットを一つずつ再適用
git cherry-pick <commit1>
git cherry-pick <commit2>

この過程で、各コミットは新しいハッシュ値を持つ新しいコミットとして再作成されます。

コミット履歴の書き換え処理

rebase の最も重要な特徴は、コミット履歴を書き換えることです。この処理により、ブランチの歴史が根本的に変更されます。

rebase による履歴変更の様子を図で示します：

mermaidflowchart TD
  subgraph "rebase 前"
    A[共通祖先] --> B[main の新しいコミット]
    A --> C[feature のコミット1]
    C --> D[feature のコミット2]
  end

  subgraph "rebase 後"
    A2[共通祖先] --> B2[main の新しいコミット]
    B2 --> C2[feature のコミット1']
    C2 --> D2[feature のコミット2']
  end

図からわかるように、rebase 後のコミット（C'、D'）は元のコミット（C、D）とは異なるハッシュ値を持つ新しいコミットになります。

bash# rebase 前後のコミットハッシュの変化例
# rebase 前
* e4f5g6h Add new feature
* h7i8j9k Fix bug in feature

# rebase 後（同じ内容だが新しいハッシュ）
* a1b2c3d Add new feature
* d4e5f6g Fix bug in feature

rebase のメリット・デメリット

rebase を使用することで得られる利点と注意点を詳しく見ていきます。

メリット：

綺麗な履歴: 線形で読みやすいコミット履歴を維持できます
簡潔性: 不要なマージコミットが作成されません
レビューしやすさ: 変更内容を追跡しやすくなります

デメリット：

履歴改変のリスク: 既存のコミットが変更されるため、共有済みブランチでは危険です
複雑なコンフリクト解決: コミット単位でのコンフリクト解決が必要な場合があります
学習コストの高さ: 安全に使用するために、より深い Git の理解が必要です

以下は rebase の特性をまとめた表です：

項目	特徴	影響
1	コミット履歴の書き換え	線形で綺麗な履歴が作成される
2	ハッシュ値の変更	すべてのコミットが新しいコミットとして再作成
3	マージコミットなし	統合の事実は履歴に明示的に記録されない

merge と rebase の違い比較表

コミット履歴への影響

merge と rebase の最も大きな違いは、コミット履歴に与える影響です。この違いを詳しく比較してみましょう。

merge による履歴の形成：

bash# merge 後の履歴例
*   a1b2c3d (HEAD -> main) Merge branch 'feature'
|\
| * e4f5g6h (feature) Add new feature
| * h7i8j9k Fix bug in feature
|/
* k9l0m1n Update README
* m1n2o3p Initial commit

rebase による履歴の形成：

bash# rebase 後の履歴例
* a1b2c3d (HEAD -> main) Add new feature
* d4e5f6g Fix bug in feature
* k9l0m1n Update README
* m1n2o3p Initial commit

この比較からわかるように、merge では分岐とマージの履歴が保持される一方、rebase では一直線の履歴となります。

実行速度とパフォーマンス

両手法の実行速度とパフォーマンスについて比較します。

| 処理項目 | merge | rebase | 説明 | | -------- | ---------------- | ------ | -------- | ----------------------------------------------------- | | 1 | 実行速度 | 高速 | 低速 | rebase は各コミットを個別に再適用するため時間がかかる | | 2 | メモリ使用量 | 少ない | 多い | rebase は一時的に複数のコミット情報を保持する | | 3 | ネットワーク転送 | 効率的 | 非効率的 | rebase 後は全てのコミットが新しくなるため転送量が増加 |

コンフリクト解決の違い

コンフリクトが発生した場合の解決プロセスにも大きな違いがあります。

merge でのコンフリクト解決：

bash# merge 時のコンフリクト
git merge feature-branch
# Auto-merging file.txt
# CONFLICT (content): Merge conflict in file.txt

# コンフリクト解決後
git add file.txt
git commit -m "Merge branch 'feature-branch'"

merge では、一度のコンフリクト解決で統合が完了します。

rebase でのコンフリクト解決：

bash# rebase 時のコンフリクト
git rebase main
# First, rewinding head to replay your work on top of it...
# Applying: Add new feature
# CONFLICT (content): Merge conflict in file.txt

# コンフリクト解決後
git add file.txt
git rebase --continue

# 次のコミットで再度コンフリクトが発生する可能性

rebase では、各コミットの再適用時にコンフリクトが発生する可能性があり、複数回の解決が必要な場合があります。

チーム開発での影響

チーム開発における両手法の影響を比較しましょう。

merge の影響：

共有ブランチでも安全に使用可能
チームメンバーの履歴に影響を与えない
マージコミットにより統合の責任者が明確

rebase の影響：

共有ブランチでは使用を避けるべき
他の開発者の作業に影響を与える可能性
より注意深い運用が必要

以下の図は、チーム開発での両手法の安全性を示しています：

mermaidflowchart LR
  subgraph "安全な操作"
    local[ローカルブランチ] -->|rebase OK| local_safe[安全]
    shared[共有ブランチ] -->|merge のみ| shared_safe[安全]
  end

  subgraph "危険な操作"
    shared2[共有ブランチ] -->|rebase| danger[履歴改変リスク]
    danger -->|影響| team[チーム全体]
  end

実践例での比較

同じ状況での merge 実行例

実際のプロジェクトでよくある状況を想定して、merge の実行例を見てみましょう。

まず、プロジェクトの初期状態を設定します：

bash# プロジェクトの初期設定
git init git-comparison-demo
cd git-comparison-demo

# 初期ファイルの作成
echo "# Git Comparison Demo" > README.md
git add README.md
git commit -m "Initial commit"

メインブランチで他の開発者による変更を追加します：

bash# main ブランチでの変更（他の開発者の作業を想定）
echo "## Project Overview" >> README.md
git add README.md
git commit -m "Add project overview"

feature ブランチを作成し、新しい機能を開発します：

bash# feature ブランチでの開発
git checkout -b feature/user-authentication
echo "## User Authentication" >> README.md
echo "- Login functionality" >> README.md
echo "- User registration" >> README.md
git add README.md
git commit -m "Add user authentication feature"

# 追加の修正
echo "- Password reset" >> README.md
git add README.md
git commit -m "Add password reset feature"

merge を実行します：

bash# main ブランチに戻って merge を実行
git checkout main
git merge feature/user-authentication

# 結果の確認
git log --oneline --graph

実行結果：

bash*   f8a9b0c (HEAD -> main) Merge branch 'feature/user-authentication'
|\
| * d5e6f7g (feature/user-authentication) Add password reset feature
| * b2c3d4e Add user authentication feature
|/
* a7b8c9d Add project overview
* 1e2f3g4 Initial commit

同じ状況での rebase 実行例

同じ状況で rebase を使用した場合の例を見てみましょう。

初期設定は merge の例と同様です。feature ブランチで rebase を実行します：

bash# feature ブランチから rebase を実行
git checkout feature/user-authentication
git rebase main

# main ブランチでの fast-forward merge
git checkout main
git merge feature/user-authentication

# 結果の確認
git log --oneline --graph

実行結果：

bash* h5i6j7k (HEAD -> main, feature/user-authentication) Add password reset feature
* e2f3g4h Add user authentication feature
* a7b8c9d Add project overview
* 1e2f3g4 Initial commit

結果の違いとその影響

両方法の実行結果を比較すると、以下のような違いが見られます。

履歴の構造：

merge: ブランチの分岐とマージが視覚的に確認できる
rebase: 線形で読みやすい履歴となる

コミットの識別：

merge: 元のコミットハッシュが保持される
rebase: 新しいコミットハッシュが生成される

追跡可能性：

merge: マージコミットにより統合のタイミングが明確
rebase: 統合の事実は履歴から読み取りにくい

この違いは、プロジェクトの要件や開発チームの方針によってメリットにもデメリットにもなり得ます。

使い分けの判断基準

merge を選ぶべき場面

merge が適している状況を具体的に説明します。

大規模なチーム開発プロジェクト： 多人数で開発を行っている場合、merge の安全性が重要になります。

bash# チーム開発での merge 例
git checkout main
git pull origin main  # 最新の変更を取得
git merge feature/payment-system
git push origin main

このように、共有ブランチでも安全に統合作業を行えます。

長期間の機能開発： 機能開発に数週間から数ヶ月かかる場合、その開発過程を履歴に残すことが重要です。

厳格な監査要件があるプロジェクト： 金融システムや医療システムなど、変更履歴の完全な追跡が必要な場合に適しています。

適用例：

状況	理由	具体的な利点
1	リリースブランチの統合	マージコミットでリリースタイミングが明確
2	ホットフィックスの適用	緊急修正の適用履歴が追跡可能
3	外部コントリビューターからの PR	貢献者の作業履歴が保持される

rebase を選ぶべき場面

rebase が効果的な状況についてお伝えします。

個人開発やローカルブランチの整理：

bash# ローカルブランチでの rebase 活用例
git checkout feature/ui-improvements
git rebase main  # main の最新状態に追従

# interactive rebase でコミットを整理
git rebase -i HEAD~3

interactive rebase を使用することで、コミットメッセージの修正やコミットの統合も可能です。

綺麗な履歴を重視するプロジェクト： オープンソースプロジェクトなど、第三者が履歴を参照することが多い場合に有効です。

継続的インテグレーション重視の開発： 線形な履歴により、自動テストやデプロイのパイプラインがシンプルになります。

適用例：

状況	理由	具体的な利点
1	プルリクエスト前の整理	レビューしやすい履歴を作成
2	実験的ブランチの統合	試行錯誤の過程を隠して結果のみ残す
3	定期的な main ブランチ追従	最新状態を保ちながら線形履歴維持

プロジェクトの方針による選択

プロジェクト全体での統合方針の決め方について説明します。

Git Flow を採用している場合：

bash# Git Flow では develop ブランチへの feature マージ
git flow feature finish user-authentication
# 内部的には merge が実行される

Git Flow では、機能の統合履歴を明確に残すため、基本的に merge を使用します。

GitHub Flow を採用している場合：

bash# GitHub Flow では main ブランチへの直接統合
# squash merge や rebase merge を選択可能
git checkout main
git rebase feature-branch  # または git merge --squash

GitHub Flow では、シンプルな履歴を重視するため、rebase や squash merge がよく使用されます。

以下の図は、プロジェクト方針による選択指針を示しています：

mermaidflowchart TD
  start[統合方法の選択] --> team_size{チーム規模}
  team_size -->|大規模| merge_choice[merge を推奨]
  team_size -->|小規模| history{履歴の重要度}
  history -->|追跡重視| merge_choice
  history -->|簡潔性重視| rebase_choice[rebase を推奨]

  merge_choice --> git_flow[Git Flow 採用]
  rebase_choice --> github_flow[GitHub Flow 採用]