Git mergeとrebaseの違い｜履歴と使い分けを初心者向けに解説

この記事でわかること

• Gitのmergeとrebaseが、どちらもブランチの変更を統合する方法であること
• 2つの方法でコミット履歴の形がどう変わるか
• 共有済みブランチをrebaseすると危険な理由
• 競合が起きたときに処理を続ける方法と、安全に中止する方法
• 初心者が迷ったときの実務的な選び方

結論・重要ポイント

1. mergeは分岐した履歴を統合し、必要に応じてマージコミットを作ります。元のコミットは書き換えません。
2. rebaseは自分のコミットを別の基点へ順に再適用し、一直線に見える履歴を作ります。再適用されたコミットのIDは変わります。
3. すでに他の人が取得している共有ブランチでは、原則としてrebaseを避けます。
4. 初心者や共有履歴を安全に統合したい場面ではmerge、まだ共有していない自分の作業履歴を整理したい場面ではrebaseが候補です。
5. 競合解消に自信がないときは、git merge --abortまたはgit rebase --abortで開始前の状態へ戻して確認できます。

対象読者と前提知識

この記事は、Gitでブランチを作れるようになり、別ブランチの変更を取り込む方法を知りたい初学者向けです。

commit、branch、switchの基本的な役割を知っていれば読み進められます。例では、統合先をmain、作業ブランチをfeature/loginとします。

MAO先生と学ぶmerge・rebase

コード・操作手順・具体例

次の例では、mainの更新をfeature/loginへ取り込みます。実行前に未コミットの変更を整理し、現在のブランチ名と作業ツリーを確認してください。

1. 現在の状態を確認する

次のコマンドは、現在のブランチ、未コミット変更、コミット履歴を確認する一式です。

git status
git branch --show-current
git log --oneline --graph --decorate --all -10

git statusに変更が表示された場合は、内容を確認してコミットするか、作業を中断します。意図が分からない変更を自動で破棄しないでください。

2. mergeでmainを取り込む

feature/loginへ移動し、mainの変更を統合します。

git switch feature/login
git merge main

履歴が分岐していれば、通常は両方の履歴を親に持つマージコミットが作られます。feature/loginがmainの祖先にあるなど、履歴をそのまま前へ進められる場合はfast-forwardになり、マージコミットが作られないこともあります。

3. rebaseでmainの先へ並べ直す

まだ他の人と共有していないfeature/loginで実行する例です。

git switch feature/login
git rebase main

Gitは、feature/login固有のコミットをmainの先へ順番に再適用します。再適用後は新しいコミットになるため、コミットIDが変わります。

4. mergeの競合を解消する

競合したファイルを編集して内容を確定した後、解決済みとして登録し、マージコミットを作ります。

git status
git add path/to/conflicted-file
git commit

解消を中止してmerge開始前へ戻る場合は、次のコマンドを使います。

git merge --abort

5. rebaseの競合を解消する

競合したファイルを編集して登録した後、停止したrebaseを続けます。複数のコミットで競合する場合は、この流れを繰り返します。

git status
git add path/to/conflicted-file
git rebase --continue

解消を中止してrebase開始前へ戻る場合は、次のコマンドを使います。

git rebase --abort

6. 統合後の履歴を確認する

操作後は、テストに加えて履歴の形も確認します。

git status
git log --oneline --graph --decorate --all -10

mergeでは分岐と統合の形が残り、rebaseでは作業コミットがmainの先へ並びます。どちらを選んでも、対象プロジェクトのテストやビルドを別途実行してください。

よくある誤解や失敗

rebaseはコミットを移動するだけでIDは変わらない

誤解です。rebaseは変更を別の基点へ再適用し、新しいコミットを作ります。コミットの親が変わるため、コミットIDも変わります。

mergeは必ずマージコミットを作る

必ずではありません。統合先をそのまま前へ進められる場合、Gitはfast-forwardでブランチの参照を進められます。必ずマージコミットを残す運用では、チームのルールと--no-ffの利用方針を確認します。

rebaseすると競合は1回しか起きない

rebaseはコミットを順に再適用します。そのため、複数のコミットで同じ周辺を変更していると、競合解消が複数回必要になることがあります。

共有済みブランチもforce pushすれば問題ない

共有履歴の書き換えは、他の人のローカル履歴や作業中コミットに影響します。チームで明示的に合意した運用を除き、他の人が利用するブランチをrebaseして強制pushしないでください。

競合したら対象ファイルを削除すればよい

削除は競合解消ではなく、ファイル自体を削除する変更になる可能性があります。git statusで競合対象を確認し、残す内容を編集してからgit addします。判断できないときは--abortで開始前へ戻します。

Q&A

初心者はmergeだけ覚えればよいですか？

最初はmergeで安全に統合する流れを理解すれば十分です。履歴の読み方と競合対応に慣れてから、共有前の自分の作業コミットを整える目的でrebaseを学ぶと理解しやすくなります。

rebase後のファイル内容はmergeと必ず同じですか？

同じ変更を正しく統合できれば最終スナップショットが同じになる場合はありますが、必ずではありません。競合解消の判断やマージ戦略によって内容が変わる可能性があるため、統合後の差分とテストを確認します。

pullでmergeかrebaseかを選ぶ必要はありますか？

git pullは取得後の統合方法としてmergeまたはrebaseを選べます。既存のチーム設定や運用と異なる方法を無断で固定せず、リポジトリのルールを確認してください。

rebase中に間違えたら元へ戻せますか？

処理中ならgit rebase --abortで開始前へ戻せます。完了後の復旧にはreflogが役立つ場合がありますが、状況に応じた判断が必要です。まず新しい変更を重ねず、履歴に詳しい人へ相談してください。

この記事のコマンドは実際に確認しましたか？

この記事の基本操作は、記事作成時にプロジェクト内の一時Gitリポジトリで確認します。実際のリポジトリではブランチ名、競合内容、保護ルールが異なるため、実行前にgit statusとチームの運用ルールを確認してください。

要点まとめ

• mergeは分岐した履歴を統合し、元のコミットを残す
• rebaseはコミットを別の基点へ再適用し、一直線の履歴を作る
• 共有済みの履歴は原則としてrebaseしない
• 迷ったらmerge、未共有の自分の作業履歴を整える場合だけ慎重にrebaseを検討する
• 競合を安全に解消できない場合は、対応する--abortで開始前へ戻す

公式資料・参考資料

• Git公式ドキュメント：git-merge
• Git公式ドキュメント：git-rebase
• Git公式ドキュメント：git-pull
• Pro Git：Rebasing
• Pro Git：Basic Branching and Merging

※Git公式資料を2026年7月2日に確認して作成しています。実務では、利用中のGitバージョンとリポジトリ固有のブランチ保護ルールも確認してください。

GitやGitHubの開発フローを相談できます

ブランチの統合方法は、コマンドだけでなく、誰がどの履歴を共有するか、レビュー後にどう公開するかまで決めると安全に運用できます。

MAO工房では、Git・GitHubのブランチ運用、レビュー手順、競合時の対応ルール整理を支援しています。お問い合わせフォームから現在の開発環境や困りごとをお知らせください。

授業に登場する3人については、MAO先生のIT授業 キャラクター紹介で確認できます。