Zenn
🔀

【図解】git mergeとrebaseの違いを完全理解！どっちを使えばいいの？

に公開
Git
GitHub
初心者向け
tech

はじめに

Gitを使っていると必ず出会うこのエラーメッセージ：

fatal: Need to specify how to reconcile divergent branches.

「--rebaseか--no-rebaseを選べ」と言われても、どっちを選べばいいの？🤔

この記事では、mergeとrebaseの違いを図解でわかりやすく解説します！

そもそも何が起きているの？

まず、このエラーが出る状況を理解しましょう。

あなた：    A---B---C（ローカルで新しいコミット）
               \
リモート：      D---E（他の人がpushしたコミット）

つまり、あなたのローカルとリモートで別々の作業が進んでしまった状態です。

Merge（マージ）とは？

図で理解するMerge

Before:
main:     A---B（共通の履歴）
               \
あなた：        C（あなたのコミット）
               \
リモート：      D---E（他の人のコミット）

After merge:
main:     A---B-------M（マージコミット）
               \     / \
                C   /   \
                 \ /     \
                  D-------E

Mergeの特徴

✅ 新しい「マージコミット」（M）が作られる
✅ 履歴が枝分かれして合流する形になる
✅ 元のコミット（C、D、E）はそのまま残る

実際のコマンド

git pull --no-rebase origin main
# または
git pull origin main  # デフォルトはmerge

Rebase（リベース）とは？

図で理解するRebase

Before:
main:     A---B（共通の履歴）
               \
あなた：        C（あなたのコミット）
               \
リモート：      D---E（他の人のコミット）

After rebase:
main:     A---B---D---E---C'（あなたのコミットが移動）

Rebaseの特徴

✅ コミットが「移植」される（C → C'）
✅ 一直線のきれいな履歴になる
✅ 元のコミットCは新しいC'に置き換わる

実際のコマンド

git pull --rebase origin main

どっちを使えばいいの？

🟢 Merge を使うべき場面

1. mainブランチ、masterブランチの場合 

# mainブランチでは基本的にmerge！
git pull --no-rebase origin main

2. すでにpushしたブランチの場合 

# 他の人と共有しているなら merge
git pull --no-rebase origin feature/shared-branch

3. チーム開発の場合

  • 履歴の追跡が重要
  • 誰がいつ何をしたか明確にしたい

🟡 Rebase を使ってもいい場面

1. まだpushしていないローカルの作業 

# ローカルだけの作業ならrebase OK
git pull --rebase origin main

2. 個人の機能ブランチ 

# 自分だけが使うブランチ
git pull --rebase origin feature/my-private-branch

3. プルリクエスト前の整理

  • コミット履歴をきれいにしたい
  • レビュアーに見やすくしたい

実践的な使い分けガイド

ケース1: メインブランチで作業中

# ❌ 危険！mainでrebaseは避ける
git pull --rebase origin main

# ✅ 安全！mergeを使う
git pull --no-rebase origin main

ケース2: 機能ブランチで一人で作業中

# ✅ OK！履歴をきれいに保てる
git pull --rebase origin main

ケース3: 複数人で同じブランチを使用

# ✅ 安全！mergeで履歴を保持
git pull --no-rebase origin feature/team-branch

よくある質問

Q: rebaseって危険なの？

A: すでに共有したコミットをrebaseすると危険です。なぜなら：

  1. コミットIDが変わる
  2. 他の人の作業に影響する
  3. 履歴の不整合が起きる

Q: mergeだと履歴が汚くなる？

A: 確かにマージコミットが増えますが、実際の開発の流れが正確に記録されるメリットがあります。

Q: 会社やチームではどっちが多い？

A: 多くのチームでは：

  • mainブランチ: merge（安全性重視）
  • 個人の機能ブランチ: rebase OK（きれいな履歴）

まとめ

迷ったらこれ！

# mainブランチなら merge
git pull --no-rebase origin main

# 個人のローカル作業なら rebase OK
git pull --rebase origin main

覚えておくべきポイント

  1. Merge: 安全だけど履歴が複雑
  2. Rebase: きれいだけど履歴を書き換える
  3. mainブランチではmergeが基本
  4. 共有前ならrebaseもOK

最初はmergeを使って慣れてきたら、適切な場面でrebaseを使い分けていきましょう！

参考リンク

GitHubで編集を提案

Discussion