はじめに
「rebaseして」「mergeして」って、何が違うの？ チーム開発でよく耳にするこの2つのコマンドは、どちらもブランチを統合する役割を持ちますが、実は履歴の扱い方がまったく異なります。
目的によって使い分けることが、Gitを使いこなす第一歩です。この記事では、図と具体例を通して、rebaseとmergeの違いをイメージで理解できるように解説します。
前提：ブランチの状況をイメージしよう
開発中によくある、以下の状況を考えてみましょう。
- チーム全体で使っている
mainブランチ - 自分の作業ブランチである
feature/add-loginブランチ
あなたのブランチを切り出した後、mainには他の人のコミット（B、C）が増えています。
現在のブランチ構成
main: A --- B --- C
feature: └── D --- E
このとき「最新のmainを取り込みたい」と思ったら、mergeかrebaseのどちらかを使います。
merge とは：「履歴をそのまま合流させる」
mergeは、2つの履歴をそのまま1つにまとめるコマンドです。
コマンド例
git checkout feature/add-login
git merge main
結果のイメージ
A --- B --- C
└── D --- E --- M
Mはマージコミットと呼ばれる新しいコミットで、これが「mainとfeatureを合流させた証」となります。
| 項目 | 詳細 |
|---|---|
| メリット | 履歴を壊さない（安全）、どのブランチから統合したのかが明確 |
| デメリット | マージコミットが増えて履歴が複雑になることもある |
| よく使う場面 |
チーム開発のmainブランチへの統合、GitHubの「Merge pull request」時 |
rebase とは：「履歴を並び替えてきれいにする」
rebaseは、自分のコミットを最新のmainの「上」に乗せ換えるコマンドです。
コマンド例
git checkout feature/add-login
git rebase main
結果のイメージ
A --- B --- C --- D' --- E'
D'とE'は新しく作り直されたコミットです。mainの最新コミット（C）を土台にして、自分の作業をやり直した形になり、履歴が一直線になります。
| 項目 | 詳細 |
|---|---|
| メリット | 履歴が一直線で見やすい（きれい）、余計なマージコミットが入らない |
| デメリット | 元の履歴を書き換える（安全ではない）、共有ブランチで使うと混乱を招く |
| よく使う場面 | 自分の作業ブランチの整理、チームにプッシュする前のローカルでの整形 |
rebaseとmergeの違いまとめ
| 比較項目 | merge |
rebase |
|---|---|---|
| 履歴の形 | 枝分かれが残る | 一直線になる |
| 履歴の安全性 | 壊さない（安全） | 書き換える（注意が必要） |
| マージコミット | あり | なし |
| チーム開発 | main統合向き |
ローカル整理向き |
| よく使う場面 | PR統合時 | 自分の作業ブランチ整理時 |
注意点：rebaseは「共有ブランチ」で使わない！
rebaseは履歴を書き換えるため、他の人がpullしている共有ブランチで実行すると履歴がズレてしまい、大きな混乱を招きます。
- 自分のローカルブランチ → OK
-
チーム共有の
mainやdevelop→ NG
Point「rebaseは1人作業専用コマンド」「mergeはチーム共有用コマンド」と覚えておくと安全です。
実務でのおすすめ使い分け
| 状況 | 推奨コマンド | 理由 |
|---|---|---|
自分の作業ブランチを最新mainに追従 |
git pull --rebase origin main |
履歴がきれいに保たれる |
チームのmainブランチに統合 |
git merge (またはPRのMergeボタン) |
履歴を壊さず安全に合流 |
| コードレビュー前にコミットを整理したい |
git rebase -i (対話的rebase) |
コミットをまとめてスッキリさせる |
まとめ
-
merge：履歴をそのまま残して安全に合流（チーム向け） -
rebase：履歴を整理してきれいに整える（個人作業向け）
どちらも「正しい・間違い」ではなく、「目的で使い分ける」ものです。あなたの開発スタイルやチームのルールに合わせて、適切なコマンドを選択しましょう！
宣伝
くすりの窓口ではエンジニアを積極採用中です！
ご興味のある方は下記リンクよりお問い合わせください！
学生向け
中途向け