git rebaseで履歴を整理する――コンフリクト解決まで初心者向け

このガイドでは、git rebaseの基本的な使い方と実践的な活用法を学びます。コミット履歴を見やすくまとめる方法、よくあるエラーの対処法、そして実務で即座に活用できるワークフローを解説します。

git rebaseとは――何ができるのか

git rebaseは、コミット履歴を再構成するGitコマンドです。ブランチの分岐点を変更したり、複数のコミットを1つにまとめたり、コミットメッセージを修正したりできます。

似たコマンドにgit mergeがありますが、大きな違いがあります。mergeは2つのブランチの履歴を統合しますが、分岐したままの状態が残ります。一方、rebaseはブランチの「土台」を変更し、一直線の履歴を作ります。チームの開発では、履歴が一直線になるため、後から追跡しやすくなります。

基本的な使い方――3つの主要パターン

1. ブランチをメインブランチに対してrebaseする

最も一般的な使い方が、フィーチャーブランチをmainブランチに対してrebaseすることです。以下の流れで作業します。

# メインブランチの最新状態を取得
git fetch origin

# フィーチャーブランチで作業中
git checkout feature/new-feature

# mainブランチの最新コミットを土台にする
git rebase origin/main

このコマンド実行後、feature/new-featureブランチのコミットが、mainブランチの最新コミットの上に「移植」されます。結果として、一直線の履歴が得られます。

2. 複数のコミットを1つにまとめる（squash）

開発中に細かいコミットが増えた場合、rebaseで複数のコミットを1つにまとめられます。これを「squash」と呼びます。

# 直前の3つのコミットをまとめる
git rebase -i HEAD~3

このコマンドを実行すると、エディタが開き、過去3つのコミットが表示されます。

pick abc1234 初回コミット
pick def5678 バグ修正
pick ghi9012 タイポ修正

2番目以降の行の「pick」を「squash」（または「s」）に変更します。

pick abc1234 初回コミット
s def5678 バグ修正
s ghi9012 タイポ修正

保存して終了すると、3つのコミットが1つにまとまり、コミットメッセージを編集できるようになります。

3. コミットメッセージを修正する（reword）

過去のコミットメッセージに誤りがあった場合も修正できます。

git rebase -i HEAD~2

エディタで「pick」を「reword」（または「r」）に変更します。

r abc1234 誤ったメッセージ
pick def5678 正しいメッセージ

保存すると、修正対象のコミットメッセージを編集できるウィンドウが開きます。

よくあるハマりポイント――コンフリクト対処法

コンフリクトが発生したときの対応

rebase中に同じ行を編集していた場合、コンフリクトが発生します。以下がエラーメッセージの例です。

CONFLICT (content): Merge conflict in app.js
error: could not apply abc1234... コミットメッセージ
hint: Resolve all conflicts manually, then run "git rebase --continue".

この場合、衝突が起きたファイルを確認して修正する必要があります。

# コンフリクトが発生しているファイルを確認
git status

# ファイルを開き、衝突部分を手動で修正
# （エディタで修正後）

# 修正完了後、ステージングしてrebaseを続行
git add app.js
git rebase --continue

すべてのコンフリクトを解決するまで、このプロセスが繰り返されます。途中で中止したい場合は、以下を実行してください。

git rebase --abort

「already up to date」エラーが出た場合

このメッセージは、既にターゲットブランチが最新の状態にあることを意味します。この場合、rebaseは必要ありません。以下を確認してください。

# 最新の状態を取得
git fetch origin

# ローカルブランチが遅れていないか確認
git log --oneline origin/main..HEAD

実務ワークフロー――プルリクエスト前の最良実践

実際のチーム開発では、プルリクエスト（PR）を送る前にrebaseを活用します。以下は推奨されるワークフローです。

# 1. フィーチャーブランチで開発
git checkout -b feature/user-auth

# コミットを複数作成
git commit -m "認証画面を追加"
git commit -m "バリデーション処理を実装"
git commit -m "テストを追加"

# 2. mainの最新状態に対してrebase
git fetch origin
git rebase origin/main

# 3. 複数の細かいコミットを1つにまとめる
git rebase -i origin/main
# ここで、最初のコミットをpick、残りをsquashに変更

# 4. プッシュ（-fは慎重に使用）
git push origin feature/user-auth -f

注意点として、rebase実行後にgit pushする場合、通常のpushでは失敗します。強制プッシュ（-f フラグ）が必要になりますが、これはチームで合意した場合のみ使用してください。既に他の開発者がこのブランチで作業している場合は避けましょう。

rebaseを使うべき場面と避けるべき場面

使うべき場面

• ローカルブランチで開発中で、まだリモートにプッシュしていない
• PRを送る前に履歴をきれいに整理したい
• チーム開発で一直線の履歴を保つルールが決まっている
• 細かいコミットを1つにまとめたい

避けるべき場面

• 既に他の開発者と共有しているブランチ（リモートにプッシュ済み）
• 複数人で同時に編集しているブランチ
• 公開されているmainやdevelopブランチ
• プロジェクトのルールでmergeを推奨している場合

トラブルシューティング――起きやすいエラー

「you are currently rebasing」エラー

rebase中にコマンドを中断したまま、別の操作をしようとした場合に出ます。

# 現在の状態を確認
git status

# rebaseを継続
git rebase --continue

# または、rebaseをやり直す
git rebase --abort

Pushが拒否された場合

rebase後のpushで「rejected」エラーが出た場合、履歴が変わったことが原因です。

# 強制プッシュで反映（ローカルブランチの場合のみ）
git push origin feature/your-branch -f

# 安全な強制プッシュオプション
git push origin feature/your-branch --force-with-lease

--force-with-leaseは、リモートの状態を確認してからプッシュするため、--fより安全です。

よくある質問

まとめ

• git rebaseはコミット履歴を再構成し、一直線にきれいに整理できるコマンド
• ローカルブランチでの開発中、PR前の履歴整理に最適
• squashで複数コミットを1つに、rewordでメッセージを修正可能
• コンフリクト発生時はファイルを修正してgit rebase --continueで続行
• 既に共有済みのブランチでは使用を避け、チームのポリシーを優先する
• --force-with-leaseを使った安全な強制プッシュで履歴を反映

git rebaseを習得すれば、コミット履歴を整理してプロフェッショナルな開発フローを実現できます。最初は小規模なローカルブランチで試し、エラーが起きてもabortで戻せることを理解しておけば、安心して活用できます。

詳細はGit公式ドキュメントをご参照ください。