Rebaseとは、Mergeとの違い、そして動作原理

Rebaseとは？

Rebase（リベース）は、現在のブランチから新しいベースポイントにコミットを移動するGit操作です。マージコミットを作成する代わりに、rebaseはソースブランチから各コミットを取得し、新しいベースの上に1つずつ適用します。結果として、分岐のない線形のコミット系列が得られます。

Rebase という名前は「re-base」（ベースを変更する）に由来します。mergeが2つのブランチを1つのポイントで結合するのに対し、rebaseはブランチ全体を新しい場所に実質的に移動し、あたかもターゲットブランチの現在の状態から開発を開始したかのように見せます。これにより、完全に順次的な作業の印象を与えます。

Atlassian、2025年によると、フィーチャーブランチにrebaseを使用するチームは、mergeのみを使用するチームと比較して、コミット履歴の分析に30%少ない時間を費やしています。線形履歴は、git blame、bisect、およびgit log --onelineによるログ表示を簡素化します。

Mergeとの基本的な違い

Merge は2つの親を持つコミットを作成してブランチを結合します。Rebase は履歴を書き換えます。変更内容は元のものと同じですが、新しいハッシュで新しいコミットが作成されます。つまり、rebaseはコミットのSHA識別子を変更するため、公開ブランチでは重要です。

Rebaseの仕組み

Rebaseのメカニズム は4つのステップで構成されます。Gitは現在のブランチとターゲットブランチの共通祖先（マージベース）を特定し、現在のブランチの各コミットをターゲットブランチの上に順次適用します。いずれかのステップで競合が発生すると、rebaseは停止して解決を待ちます。

# 初期状況：featureブランチがdevelopより3コミット遅れている
git checkout feature/new-login
git rebase develop

# Gitはfeatureから3つのコミットを取得し、developの上に適用する
# 競合がなければ — rebaseは自動的に完了する
# 競合があれば — Gitは競合するコミットで停止する

Rebase後、フィーチャーブランチ にはdevelopのすべてのコミットと、developの継続として表示される自身のコミットが含まれます。これにより、マージコミットを作成せずにfast-forwardでdevelopにマージできます。

段階的なプロセス

詳細な例を見てみましょう。開発者がdevelopからフィーチャーブランチを作成し、2つのコミットを行い、その間に他の開発者がdevelopに3つのコミットを追加しました。Rebaseは2つのフィーチャーコミットを新しい位置に移動し、新しいSHAでコピーを作成します。

# 1. featureブランチを作成する
git checkout -b feature/payment-refactor develop

# 2. featureでコミットを行う
git commit -m "refactor: extract payment validation"
git commit -m "refactor: add payment gateway interface"

# 3. developを更新する（同僚の作業）
git checkout develop
git pull

# 4. 新しいdevelopの上にfeatureをリベースする
git checkout feature/payment-refactor
git rebase develop

# 5. これでfeatureをfast-forwardでマージできる
git checkout develop
git merge feature/payment-refactor

ステップ4で競合が発生した場合、Gitは問題のあるコミットで停止します。開発者は競合を解決し、git addを実行してからgit rebase --continueを実行します。コミットをスキップするには — git rebase --skip、rebase全体をキャンセルするには — git rebase --abort。

空のコミットの自動スキップ

--emptyフラグ は、空のコミット（コミットのすべての変更がターゲットブランチにすでに存在する状況）に対するrebaseの動作を制御します。デフォルトでは、rebaseは停止して決定を求めます。--empty=dropを使用すると、Gitは停止せずに自動的にそのようなコミットをスキップし、多数のコミットを含む大量リベースを高速化します。

インタラクティブRebase

インタラクティブrebase（git rebase -i）は、コミット履歴を編集するための強力なツールです。コミットのリストとキーコマンド（pick（保持）、reword（メッセージ変更）、edit（内容変更）、squash（前のコミットと統合）、fixup（メッセージなしで統合）、drop（削除））を含むエディターが開きます。

# 最後の4つのコミットのインタラクティブrebase
git rebase -i HEAD~4

# エディタにrebase計画が表示されます：
# pick a1b2c3 feat: add login screen
# pick d4e5f6 fix: login validation
# pick g7h8i9 fix: login layout
# pick j0k1l2 docs: add login comments

# 次のように変更：
# pick a1b2c3 feat: add login screen
# squash d4e5f6 fix: login validation
# squash g7h8i9 fix: login layout
# drop j0k1l2 docs: add login comments

結果：3つのコミット（ログイン画面、バリデーション、レイアウト）が1つに統合され、コメントのあるコミットは削除されます。これにより、ドラフトや修正なしで、コードレビュー用のクリーンな履歴を提出できます。インタラクティブrebaseは、Pull Requestの前にフィーチャーブランチを準備するための標準ツールです。

Rebase vs Merge：比較

RebaseとMerge は同じ問題 — 変更の統合 — を解決しますが、根本的に異なる方法で行います。どちらを選ぶかは、git logでどのような履歴を見たいか、そして誰があなたのブランチで作業しているかによって異なります。

実用的なルール：共有ブランチ（develop、main）への統合にはmergeを使用し、個人のフィーチャーブランチを最新状態にするにはrebaseを使用します。多くのチームは両方を組み合わせています。developにフィーチャーをrebaseし、その後developに--no-ff mergeします。

git bisectへの影響

Git bisect は、リグレッションを導入したコミットを見つけるためのツールです。mergeを使用する場合、git bisectは両方の親を考慮してマージコミットを正しく通過します。Rebaseを使用すると、履歴が線形で分岐を必要としないため、bisectはより速く動作します。ただし、コミットがチームに知られるようになった後にrebaseが行われた場合、元のSHAは失われ、bisectが問題のコミットを見つけられない可能性があります。

Rebaseを使用するタイミング

Rebase は3つのシナリオで最適です：Pull Request用のフィーチャーブランチの準備、main/developの現在の状態への個人ブランチの更新、マージ前の履歴のクリーンアップ。それぞれの場合において、rebaseはチームワークにリスクを与えることなく履歴の可読性を向上させます。

Pull Request の前に、ドラフトコミット（WIP、レビュー後の修正）を意味のある論理単位に結合するためにインタラクティブrebaseを実行することをお勧めします。これによりコードレビューが容易になります。レビュアーは15の小さなコミットではなく、明確なメッセージを持つ3〜5の構造化された変更を確認できます。

フィーチャーブランチの更新 には、不要なマージコミットを作成しないため、mergeよりもrebaseが推奨されます。フィーチャーブランチ内で定期的にgit rebase developを実行すると、最終的なマージに10個のマージコミットのカスケードは発生せず、developの上にクリーンなフィーチャーコミットのみが残ります。

マージ前のインタラクティブrebaseによる履歴のクリーンアップ により、軽微な修正（タイプミス、フォーマット）を隠し、機能ごとにコミットをグループ化できます。GitメッセージはConventional Commits規約（fix:、feat:、refactor:、docs:）に従うべきで、これにより自動的にchangelogが生成されます。

Rebaseのリスクとルール

Rebase は、誤って適用すると危険な操作です。主なリスクは、公開された履歴を書き換えることです。開発者が他の人がすでにプッシュして使用しているブランチをrebaseすると、それらのローカルコピーが同期しなくなり、データ損失のリスクを伴うforce-pullを実行する必要が生じます。

• 黄金律：共有リポジトリにすでに存在するコミットは決してrebaseしないでください。これは、チームの他のメンバーがアクセスできるブランチにも適用されます
• Force push：ローカルフィーチャーブランチのrebase後は、--force-with-leaseフラグを使用したプッシュが必要です。これは、サーバー上で誰かがブランチを更新したかどうかをチェックするため、--forceよりも安全です
• コンテキストの喪失：rebaseは、フィーチャーブランチがいつ、どのブランチから作成されたかに関する情報を破棄します。ブランチの作成日を保持することが重要な場合は、mergeを使用してください
• 競合：rebase中は、各コミットごとに個別に競合を解決する必要があり、コミット数が多いと面倒になる可能性があります

リスクを最小限に抑える ために、次のルールに従ってください。公開されていない個人ブランチにのみrebaseを使用します。ブランチがすでに共有リポジトリにある場合は、--no-ff付きのmergeを使用します。公開されたブランチをrebaseする必要がある場合は、チームに事前に警告し、force pushを調整してください。

危険なrebaseに対する自動保護 は、サーバーサイドフックを通じて実装されます。Gitサーバーのpre-receiveフックは、プッシュが公開されたコミットを書き換えるかどうかをチェックできます。GitHubとGitLabは保護されたブランチの組み込み保護を提供しており、管理者が保護を解除しない限り、force pushはブロックされます。