【Git】git rebaseとmergeの違い・使い分けを徹底解説

Gitユーザにお勧めの本 ↗

初心者向け

いちばんやさしいGit&GitHubの教本 第3版 人気講師が教えるバージョン管理＆共有入門 「いちばんやさしい教本」シリーズ

難易度

実用性

読みやすさ

こんな人におすすめ： Gitをこれから使い始める人、挫折した経験がある人

とにかく挫折しない丁寧な解説。チーム開発での基本的な流れを確実にマスターできます。

Amazon 🔴 楽天

改訂2版 わかばちゃんと学ぶ Git使い方入門

難易度

実用性

読みやすさ

こんな人におすすめ： マンガで楽しくGitを学びたい人

漫画形式で視覚的にイメージしやすい。Git特有の難しい用語も、物語を通して自然に理解できます。

Amazon 🔴 楽天

独習Git

難易度

実用性

読みやすさ

こんな人におすすめ： Gitの内部構造や高度な機能を学びたい人

コマンドの裏側で何が起きているかを丁寧に解説。プロとしてGitを使いこなすためのバイブルです。

Amazon 🔴 楽天

📚 ITエンジニア向けおすすめ技術書・関連書籍まとめはこちら

「機能追加ブランチの作業が終わったけれど、git mergeとgit rebaseのどちらを使うべきか迷う…」「チームメンバーから『rebaseを使って履歴を綺麗にして』と言われたものの、何をしているのか怖くて実行できない」といった悩みを抱えていませんか？

複数人で開発を進める上で、ブランチの統合方法はプロジェクトの品質やコードレビューの効率に直結する重要な要素です。

この記事を読むことで、git mergeとgit rebaseの根本的な仕組みの違いが理解できるようになり、それぞれの特徴に応じた正しい使い分けができるようになります。結果として、コンフリクトが発生した場合にも落ち着いて対処しながら、プロジェクトに適したコミット履歴を維持できるようになります。

git mergeとgit rebaseの基本的な違い

GitGit [ギット]ソースコードの変更履歴を管理する分散型バージョン管理システムで他のブランチの変更を取り込む際、主に利用されるのが git merge と git rebase です。どちらも「ブランチを統合する」という目的は同じですが、歴史（履歴）をどのように記録するかというアプローチが大きく異なります。

git mergeの特徴とメリット・デメリット

git merge は、別のブランチの変更を現在のブランチに統合するコマンドです。履歴が分岐している場合はマージコミットを作成しますが、Fast-forwardできる場合は、デフォルトではマージコミットを作成せずブランチを先に進めます。

• メリット:
  • 履歴の改変を行わないため安全（誰がいつどのブランチを統合したのかの事実がそのまま残る）。
• デメリット:
  • 頻繁にマージを繰り返すと、コミット履歴が網の目のようになり、時系列が追いづらくなる（スパゲッティ履歴）。

git rebaseの特徴とメリット・デメリット

git rebase（リベース）は、文字通り「ベース（基準）を付け替える」操作です。自分の作業ブランチの起点（ベース）を、統合先の最新のコミット位置に移動させます。

• メリット:
  • 通常のrebaseでは、作業ブランチのコミットを新しいベースの上に再適用するため、履歴を直線的に整理できます。
  • コミット履歴が直線的になり、変更の流れを追いやすくなる。
• デメリット:
  • 既存のコミットハッシュ（ID）が書き換わるため、他の開発者と共有しているブランチで実行すると、リモートと他のメンバーのローカル環境との間で履歴の不整合が発生し、同期が難しくなる。
  • コミットを順番に再適用するため、コミット数によっては複数回コンフリクトを解決する必要があります。

図解：マージコミットの有無と履歴の違い

視覚的に両者の違いを理解するために、main ブランチから feature ブランチを切って作業し、再度 main に統合するケースを比較します。

git merge の場合

以下は、main と feature の両方に新しいコミットが存在するため、Fast-forwardできないケースです。 feature ブランチのコミット履歴（C3, C4）と、その間に進んだ main ブランチの履歴（C5）が、マージコミット（M）によって一つに結ばれます。

1
  C1 --- C2 --- C5 --------- M (main)
2
        \                   /
3
         C3 --- C4 (feature)

git rebase の場合

feature ブランチで行ったコミット（C3、C4）を、main の最新コミット（C5）を新しいベースとして再適用します。その結果、新しいコミット（C3'、C4'）が作成され、履歴が一本道になります。

1
  C1 --- C2 --- C5 (main)
2
                \
3
                 C3' --- C4' (feature - rebased)

補足：Fast-forward（早送り）マージ 上記の図はベースを付け替えた直後の状態です。この状態で main ブランチに切り替えて git merge feature を実行すると、main の先端である C5 が C4' の祖先にあたるためFast-forwardが可能であり、新たなマージコミットは作成されません。main ブランチがそのまま C4' まで早送りされ、完全な一本道として統合が完了します。

シーン別！mergeとrebaseの正しい使い分け

実務の現場では、どちらか一方だけを使えばよいというわけではありません。状況に応じた使い分けが求められます。

ローカルブランチの最新化にはrebase

自分が作業中のローカルブランチ（例: feature/login）で行ったコミットを、最新の main の上に再適用したいときは git rebase が適しています。

手順例:

1
# 1. 現在作業中のfeatureブランチにいることを確認
2
git checkout feature/login
3

4
# 2. mainの最新情報を取得
5
git fetch origin
6

7
# 3. mainの変更を自分のブランチのベースに再適用
8
git rebase origin/main

これにより、余計なマージコミットを挟むことなく、常に最新のコードベース上で自分の作業を続けることができます。

複数人で共有するリモートブランチへの統合にはmerge

機能開発が完了し、本番やステージング環境のブランチ（main や develop）へコードをマージする際は、基本的には git merge（特にプルリクエストのマージ機能）を使用するのが一般的な慣習です。

※ただし、これは絶対的なルールではありません。GitHubGitHub [ギットハブ]Gitリポジトリをホストし、共同開発を支援するWebサービスなどのプラットフォームでは「Squash and merge」や「Rebase and merge」をチームの標準ルールとしている場合もあります。所属チームの運用ルールに従うことが重要です。

理由: 共有ブランチに対してローカルから git rebase を行い強制プッシュなどをすると、他の開発者のローカル環境との間でコミット履歴の不整合（歴史の改変）が生じ、チーム全体の開発フローに悪影響を与える可能性があるためです。

git rebase実行時の注意点とコンフリクト対策

git rebase を実行する際、最も気をつけるべきなのは 「すでに他の開発者と共有しているブランチのコミットを、安易に書き換えない」 ということです。

自分しか利用していないリモートの作業ブランチでは、rebase後に強制プッシュする運用が行われることもありますが、チームのルールに従うことが重要です。コンフリクトが発生した際の流れを確認しておきましょう。

ステップ1: rebase中にコンフリクトが発生した場合

リベース中は、コミットを1つずつ順番に適用していくため、途中でコンフリクトが発生すると処理が一時停止します。

1
git rebase origin/main
2
# 自動適用中にコンフリクトが発生すると以下のようなメッセージが出る
3
# Auto-merging src/index.js
4
# CONFLICT (content): Merge conflict in src/index.js
5
# error: could not apply 3a4f2b1... fix bug

ステップ2: コードを修正してインデックスに追加

コンフリクトが発生したファイル（例: src/index.js）をエディタで開き、競合箇所を手動で修正します。修正完了後、ファイルをステージングします。

1
git add src/index.js

ステップ3: rebaseを続行する

git commit は行わず、以下のコマンドでリベースの処理を再開させます。

1
git rebase --continue

すべてのコミットの適用が完了すると、Successfully rebased and updated refs/heads/... と表示され、リベースが完了します。

もし途中でやり直したくなった場合 リベース作業を中断して元の状態に戻したいときは、以下のコマンドを実行してください。

1
git rebase --abort

まとめ

本記事では、git merge と git rebase の違いと、それぞれの適切な使い分けについて解説しました。

• git merge:
  • 分岐している場合はマージコミットを作成し、分岐の履歴をそのまま残せる。
  • Fast-forwardできる場合は、マージコミットを作成せずブランチを先に進める。
  • 複数人で共有するブランチへの統合や、履歴の改変をしたくない安全第一の場面で使用する。
• git rebase:
  • 通常のrebaseでは、履歴のベースを付け替え、コミットを新しいベースの上に再適用することで、履歴を直線的に整理できる。
  • 自分のローカルブランチを最新化する場面で使用する。
• 注意点:
  • 他の開発者と共有しているブランチに対して、安易に git rebase を行わない。

「履歴を事実としてそのまま残したいのか、それとも履歴を整理して直線化したいのか」という観点で使い分け、チームやプロジェクトの規約に合わせたスマートなGit運用を目指しましょう。

おすすめ この記事に関連する技術本

改訂2版 わかばちゃんと学ぶ Git使い方入門

Amazon 🔴 楽天

この記事を書いた人

Z (ITナレッジライフ)

現役のITエンジニア。Linux、プログラミング、IT用語など、日々の業務で得た「痒いところに手が届く」技術情報を発信しています。

プロフィールと編集ポリシーを見る →