ゼロから構築！GitインタラクティブリベースでPRを爆速化する整理術

リモートにプッシュしたPRブランチ、レビュー待ちの間にたくさんのWIPコミットが溜まってしまい、レビューアに「コミット履歴が汚い」「何が変わったのか分かりにくい」と言われた経験はありませんか？

この記事では、Git Interactive Rebase を活用して、ごちゃごちゃしたコミット履歴を美しく整理し、レビューしやすい高品質なPRを爆速で作成する具体的な手順とワークフローを解説します。これを読めば、もうコミット履歴で悩むことはなくなり、チーム開発の効率も格段に向上するでしょう。

Git Interactive Rebaseとは？基本を理解する

このセクションでは、Gitの rebase コマンドとそのインタラクティブモードが何であるか、そしてなぜそれが重要なのかを解説します。

git rebase は、コミットのシーケンスを新しいベースコミットに移動または結合するGitコマンドです。これにより、ブランチの履歴をクリーンで直線的に保つことができます。特に、git rebase -i (インタラクティブモード) を使用すると、リベース中に各コミットをどのように処理するかを詳細に制御できるようになります。これは、PRを出す前のコミット履歴の整理に非常に強力なツールです。

インタラクティブモードでできること

git rebase -i で利用できる主要な操作を理解することで、コミット履歴を自由に操ることができます。

• pick (p): コミットをそのまま含めます。
• reword (r): コミットメッセージを編集します。
• edit (e): コミットの内容（ファイル変更など）を修正したり、さらにコミットを追加したりするために、リベースプロセスを一時停止します。
• squash (s): 複数のコミットを1つに結合し、新しいコミットメッセージを作成します。
• fixup (f): 複数のコミットを1つに結合しますが、前のコミットのメッセージを再利用します（新しいメッセージの入力をスキップします）。
• drop (d): コミットを履歴から完全に削除します。
• コミットの順序変更: エディタ内でコミット行を移動することで、コミットの適用順序を変更できます。

これらの操作を組み合わせることで、複雑な開発履歴を論理的で分かりやすい一連のコミットに変換できます。

Git Interactive Rebaseの具体的な手順とワークフロー

ここでは、実際の開発シナリオを想定し、Git Interactive Rebase を使ってコミット履歴を整理する具体的な手順をステップバイステップで解説します。

前提・環境設定

Gitのバージョンは2.44.0を基準とします。
リベース中に開かれるエディタをVSCodeに設定しておくと便利です。以下のコマンドで設定できます。

git config --global core.editor "code --wait"

この設定により、Gitがコミットメッセージ編集などでエディタを開く際にVSCodeが起動し、変更を保存してVSCodeを閉じるとGitプロセスが続行されます。

1. インタラクティブリベースの開始

まず、どの範囲のコミットを整理するかを決定し、git rebase -i コマンドを実行します。

直近N個のコミットを対象にする場合

最も一般的なのは、直近のいくつかのコミットを整理するケースです。例えば、直近3つのコミットを対象にするには HEAD~3 を指定します。

git rebase -i HEAD~3

特定のコミットまでを対象にする場合

ある特定のコミット（例: abc1234）以降のコミットを対象にしたい場合は、そのコミットのハッシュを指定します。この場合、指定したコミット自体はリベースの対象に含まれません。

git rebase -i abc1234

ベースブランチを基準にリベースする場合

フィーチャーブランチを main ブランチの最新の状態に合わせつつ、コミット履歴を整理したい場合は、main ブランチをベースに指定します。

git rebase -i main

このコマンドを実行すると、設定したエディタが開かれ、対象となるコミットがリストアップされます。

2. リベースエディタでの操作

git rebase -i HEAD~3 を実行した場合のエディタの表示例を基に、具体的な操作を見ていきましょう。

pick a1b2c3d "WIP: feature A"
pick e4f5g6h "Add feature A part 1"
pick i7j8k9l "Fix typo in feature A"

# Rebase 1234567..i7j8k9l onto 1234567 (3 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) for each commit
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to re-use the given commit's
# .       message but edit it.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

2.1. コミットのスカッシュ (squash) とフィックスアップ (fixup)

複数の小さなコミットやWIPコミットを、1つの論理的なコミットにまとめたい場合によく使います。
例えば、「WIP: feature A」という最初のコミットに、後の2つのコミットを結合して1つにしたい場合：

pick a1b2c3d "WIP: feature A"
squash e4f5g6h "Add feature A part 1"
fixup i7j8k9l "Fix typo in feature A"

エディタを保存して閉じると、pick と squash で指定したコミットメッセージ（この例では a1b2c3d と e4f5g6h）を結合するためのエディタが開きます。fixup で指定した i7j8k9l のコミットメッセージは破棄されます。ここで新しいコミットメッセージを記述し、保存して閉じるとリベースが続行されます。

2.2. コミットメッセージの変更 (reword)

既存のコミットメッセージをより適切で分かりやすいものに変更したい場合に使います。
例えば、2番目のコミットメッセージを修正したい場合：

pick a1b2c3d "WIP: feature A"
reword e4f5g6h "Add feature A part 1" # ここを "Add user registration feature" などに変更したい
pick i7j8k9l "Fix typo in feature A"

エディタを保存して閉じると、e4f5g6h のコミットメッセージを編集するエディタが開きます。新しいメッセージを入力して保存すると、リベースが続行されます。

2.3. コミットの編集 (edit)

コミットの内容自体（追加・削除ファイルやコード変更）を修正したい場合に使います。例えば、最初のコミットにファイルを追加し忘れた場合：

edit a1b2c3d "WIP: feature A" # このコミットで一時停止し、内容を修正する
pick e4f5g6h "Add feature A part 1"
pick i7j8k9l "Fix typo in feature A"

エディタを保存して閉じると、リベースプロセスが a1b2c3d の場所で一時停止し、作業ツリーはそのコミットの状態に戻ります。

# ファイルを追加・修正
echo "new content" > new_file.txt
git add new_file.txt

# コミットを修正（メッセージは変更しない）
git commit --amend --no-edit

# リベースを続行
git rebase --continue

git commit --amend --no-edit は、直前のコミットの変更内容を現在のステージングエリアの内容で上書きし、コミットメッセージは変更しないオプションです。

2.4. コミットの削除 (drop)

不要なコミットを履歴から完全に削除したい場合に使います。該当する行を drop に変更するか、行自体を削除します。

pick a1b2c3d "WIP: feature A"
drop e4f5g6h "Add feature A part 1" # このコミットを削除する
pick i7j8k9l "Fix typo in feature A"

3. コンフリクトの解決

Git Interactive Rebase 中にコンフリクトが発生した場合、Gitはプロセスを一時停止し、コンフリクトを解決するように促します。

1. git status でコンフリクトしているファイルを確認します。
2. エディタでコンフリクトマーカー (<<<<<<<, =======, >>>>>>>) を手動で修正し、コンフリクトを解決します。
3. git add <解決したファイル> で変更をステージングします。
4. git rebase --continue でリベースを続行します。
   注意: リベース中のコンフリクト解決では、git commit は不要です。git add 後に git rebase --continue を実行するだけで、Gitが修正をコミットに適用してくれます。

4. リモートへの強制プッシュ

リベースはコミット履歴を書き換える操作です。そのため、既にリモートリポジトリにプッシュ済みのブランチをリベースした場合は、その変更をリモートに反映させるために強制プッシュが必要です。

git push origin my-feature-branch --force-with-lease

--force-with-lease は、--force よりも安全なオプションです。これは、リモートブランチがローカルで認識している状態から変更されていないことを確認してから強制プッシュを行います。もし他の誰かがその間にリモートブランチを更新していた場合、プッシュは拒否され、予期せぬ変更の上書きを防ぐことができます。

つまずきやすいポイントと回避策

Git Interactive Rebaseは強力ですが、いくつかの落とし穴があります。ここでは、よくある問題とその回避策を解説します。

共有ブランチのリベースによる影響

このセクションでは、共有ブランチをリベースする際の危険性と、それを避けるための方法を学びます。

ハマりどころ: 既にリモートにプッシュされ、他の開発者が作業している共有ブランチをリベースすると、他の開発者の履歴と自分の履歴が乖離し、複雑なマージコンフリクトやデータ損失を引き起こす可能性があります。

回避策:

• 共有されていないローカルブランチでのみリベースを使用します。 これが最も安全な使い方です。
• 共有ブランチをリベースする必要がある場合は、チームと密に連携し、全員が変更を認識していることを確認します。 事前に合意形成をしましょう。
• 共有ブランチでは、履歴を書き換えない git merge を使用することを検討します。

リベース中のコンフリクトの繰り返し発生

このセクションでは、同じコンフリクトが何度も発生する問題と、その効率的な解決策について解説します。

ハマりどころ: 長期間運用されているフィーチャーブランチや、複数のフィーチャーブランチを main にリベースする際に、同じコンフリクトが何度も発生することがあります。

回避策:

• git rerere (reuse recorded resolution) 機能を有効にします。 これは、以前に解決したコンフリクトの解決方法をGitに記憶させ、同じコンフリクトが再度発生したときに自動的に解決する機能です。

  git config --global rerere.enabled true
  # または、現在のリポジトリのみで有効にする場合
  git config --local rerere.enabled true
  

• 継続的インテグレーション (CI) を導入し、ブランチを頻繁に main と同期することで、コンフリクトの発生を最小限に抑えます。

• コミットのスコープを小さく保ち、関連性のない変更を1つのコミットにまとめないようにします。

リベース中に誤ってコミットしてしまう

リベース中のコンフリクト解決と通常のマージコンフリクト解決の違いを理解します。

ハマりどころ: マージコンフリクトの解決ではコミットが必要ですが、リベース中のコンフリクト解決では git add の後に git rebase --continue を実行するのが正しい手順です。誤って git commit を実行してしまうことがあります。

回避策:

• 誤ってコミットしてしまった場合は、git reset --soft HEAD~1 を実行して、コミットを取り消し、変更をステージングされた状態に戻します。その後、git rebase --continue を実行します。

リベースの途中で迷子になる、元の状態に戻したい

リベースを中断したり、以前の状態に戻したりする方法を知ることで、安心して作業を進められます。

ハマりどころ: リベース中に何が起こっているのか分からなくなったり、意図しない変更が加えられたりして、元の状態に戻したい場合があります。

回避策:

• リベースを開始する前に、バックアップブランチを作成しておくと安全です (git branch backup-feature)。

• git rebase --abort コマンドを使用すると、リベース開始前の状態にブランチを戻すことができます。

• git reflog コマンドを使用すると、Gitリポジトリで行われたすべての操作の履歴を確認でき、過去の任意の時点に戻ることができます。

  git reflog
  # 例: HEAD@{5} の状態に戻したい場合
  git reset --hard HEAD@{5}
  

設計上のトレードオフとベストプラクティス

Git Interactive Rebase を効果的かつ安全に活用するための、設計上の考慮事項と推奨されるプラクティスをまとめます。

トレードオフ

• 履歴のクリーンさ vs. 履歴の忠実性: リベースはコミット履歴を書き換えるため、履歴が直線的で読みやすくなりますが、元の分岐履歴は失われます。マージは分岐履歴を保持しますが、マージコミットが増えることで履歴が複雑になることがあります。どちらを選ぶかは、プロジェクトのポリシーやチームの合意に依存します。
• ローカルでの利用 vs. 共有ブランチでの利用: ローカルでのコミット整理には非常に強力ですが、共有ブランチでの利用は他の開発者に影響を与えるリスクが伴います。

ベストプラクティス

• プッシュする前にリベースする: コミットをリモートリポジトリにプッシュする前に、ローカルブランチでコミット履歴を整理するためにリベースを使用しましょう。これにより、リモートにプッシュされるコミットは常にクリーンな状態になります。
• 意味のあるコミットメッセージを使用する: 最終的なコミットメッセージは明確で、変更内容を正確に反映しているべきです。レビューアがコミットメッセージだけで変更の意図を理解できるように心がけましょう。
• 論理的なコミットを維持する: 1つのコミットには1つの論理的な変更のみを含めるようにします。これにより、コードレビューが容易になり、デバッグもしやすくなります。
• リベース後にテストを実行する: コンフリクトの解決やコミットの変更によって予期せぬバグが導入される可能性があるため、リベース後は必ずテストを実行し、変更が正しく機能することを確認します。
• --force-with-lease を使用する: リベース後にリモートにプッシュする際は、--force ではなく --force-with-lease を使用して、より安全に強制プッシュを行います。
• バックアップブランチを作成する: 複雑なリベースを行う前には、念のためバックアップブランチを作成しておくと、万が一の際に元の状態に戻しやすくなります。
• ベースブランチを定期的にプルする: コンフリクトを最小限に抑えるために、フィーチャーブランチをベースブランチの最新の変更で頻繁に更新しましょう。
• チームとのコミュニケーション: 共有ブランチでリベースを行う場合は、チームメンバーと変更についてコミュニケーションを取り、調整を図ることが不可欠です。

まとめ

本記事では、Git Interactive Rebaseの基本的な使い方から、PRワークフローでの活用、具体的な操作例、そしてよくあるつまずきポイントとその回避策までを網羅的に解説しました。

Git Interactive Rebaseを習得することで、WIPコミットを整理したり、小さな修正をまとめることで、レビューしやすい、高品質なコミット履歴を作成できるようになります。これにより、コードレビューの効率が向上し、チーム全体の開発速度も加速するでしょう。

今日からあなたの開発ワークフローにGit Interactive Rebaseを取り入れ、よりクリーンで効率的なGit運用を目指しましょう。さらに詳細な情報はGit公式ドキュメントを参照してください。