Gitのrebaseとmergeの違い｜使い分けの基準を解説

Gitのブランチを統合する操作には、mergeとrebaseの2つがあります。両者は最終的に「ブランチを合流させる」点では同じですが、履歴の見え方と運用ポリシーが異なります。本記事では、両者の違いと使い分けの基準を解説します。

merge とは

2つのブランチを「合流させる新しいコミット」を作る統合方法。元のコミット履歴がそのまま残ります。

git checkout main
git merge feature
# main: A -B -C
#                \
# feature:        D -E
#                       \
# result:         A -B -C -M (merge commit)
#                    \    /
#                     D -E

rebase とは

featureブランチのコミットを、mainの最新の上に「並べ直す」操作。履歴が一直線になります。

git checkout feature
git rebase main
# Before: main: A-B-C   feature: B-D-E
# After:  main: A-B-C   feature:     C-D'-E'

項目別比較

• 履歴：merge=分岐保持、rebase=直線化
• マージコミット：mergeはあり、rebaseは無し
• SHAが変わるか：rebaseはコミットIDが書き換わる
• push済みブランチでの危険度：rebaseは高い（force-push必要）

使い分けの基準

mergeが向くケース

• 共有ブランチ（main、develop）の統合
• 履歴を改変したくない
• 大規模ブランチで全体構造を残したい

rebaseが向くケース

• 個人ブランチを最新mainに追従させる
• 履歴をきれいにしてPRレビューしやすくしたい
• 細かいコミットをsquashして1つにまとめる

運用パターン例

• featureブランチをmainに追従 → rebase
• レビュー前にコミットを整理 → interactive rebase
• PRをmainにマージ → squash merge or merge
• 共有ブランチ間の統合 → merge

force-pushの注意

rebase後にすでにpush済みなら、git push --force-with-leaseでリモートを更新します。他人と共有しているブランチでは強制プッシュは避けるか、事前に合意を取りましょう。

まとめ

「個人ブランチはrebase、共有ブランチはmerge」が基本指針です。履歴をきれいにしたいか、改変リスクを避けたいかで判断しましょう。PR運用ではsquash mergeを使ってmainを直線に保つチームも多いです。