Git rebaseとは?使い方から実践例までわかりやすく解説
はじめに
Gitを使ったバージョン管理を学んでいると、「rebase」という用語に出会う人が多いでしょう。rebaseはマージ(merge)と並ぶ重要な機能ですが、初心者にとっては理解しにくい概念です。この記事では、Git rebaseとは何か、どのように使うのか、そして実務的な注意点について、初心者でもわかりやすく解説します。
第1章:Git rebaseの原因と概念の説明
Git rebaseとは何か
Git rebaseは、「別のブランチの最新の状態を基準として、現在のブランチのコミット履歴を再構築する」機能です。「rebase」という言葉は「base(基準)を改める」という意味です。
複数の開発者がそれぞれのブランチで作業している場合、メインブランチが更新されます。この時、自分のブランチをメインブランチの最新状態に同期させるために、rebaseが使われます。
mergeとrebaseの違い
Gitでブランチを統合する方法は主に2つあります:
merge(マージ)の場合:
- 2つのブランチの変更を統合するマージコミットが作成される
- 履歴がツリー状になり、複数の分岐が残る
- 履歴は複雑だが、全ての変更が記録される
rebase(リベース)の場合:
- コミット履歴が一直線になる
- マージコミットが作成されない
- 履歴がきれいで読みやすい
rebaseが必要な原因
以下のような場面でrebaseが必要になります:
1. コミット履歴を整理したい
マージを繰り返すとコミット履歴が複雑になります。rebaseを使うことで、線形で読みやすい履歴にできます。
2. メインブランチの最新状態に同期したい
他の開発者がメインブランチにコミットを追加した場合、自分のブランチもそれに追従させたいことがあります。
3. コミットを再編成したい
複数のコミットを1つにまとめたり、順序を変更したり、内容を修正したりする場合があります。
第2章:Git rebaseの解決手順
基本的なrebaseの手順
ステップ1:現在のブランチを確認
まず、現在どのブランチで作業しているかを確認します。
git branch
ステップ2:rebaseするブランチに移動
例えば、develop ブランチの最新状態を feature ブランチに反映させたい場合:
git checkout feature
git rebase develop
ステップ3:コンフリクトが発生した場合は解決
rebase中にコンフリクト(競合)が発生することがあります。その場合は、ファイルを編集して解決します。
git status
ステップ4:ファイルの修正と確認
コンフリクトのあるファイルを開き、手動で編集します。編集後、ステージングエリアに追加します。
git add ファイル名
ステップ5:rebaseを続行
全てのコンフリクトを解決したら、rebaseを続行します。
git rebase --continue
ステップ6:rebaseをキャンセルしたい場合
もしrebase中に問題が発生して、rebaseを中止したい場合は:
git rebase --abort
インタラクティブrebaseの使い方
インタラクティブrebaseは、複数のコミットを修正・統合・並び替えできる強力な機能です。
基本的な使い方:
git rebase -i HEAD~3
このコマンドは、最新から遡って3つのコミットをインタラクティブに編集できます。
実行するとエディタが開き、以下のような画面が表示されます:
pick a1b2c3d コミットメッセージ1
pick d4e5f6g コミットメッセージ2
pick h7i8j9k コミットメッセージ3
利用可能なコマンド:
pick:そのコミットを使用reword:コミットメッセージを編集squash:前のコミットに統合fixup:前のコミットに統合(メッセージを破棄)drop:コミットを削除
第3章:Git rebaseのコード例
例1:基本的なrebase
# 現在の状態を確認
git log --oneline
# develop ブランチを確認して更新
git fetch origin
git checkout develop
git pull origin develop
# feature ブランチに切り替え
git checkout feature
# develop ブランチの最新状態をベースに rebase
git rebase develop
# rebase 後の履歴を確認
git log --oneline
例2:コンフリクトの解決
# rebase を開始
git rebase develop
# コンフリクトが発生した場合
# ファイルを確認
git status
# コンフリクトのあるファイルを編集
# (エディタで <<<<<<< HEAD と >>>>>>> develop の間を修正)
# ファイルをステージングして追加
git add src/main.js
# rebase を続行
git rebase --continue
# もし中断する場合
git rebase --abort
例3:複数のコミットを1つにまとめる
# 最新の3つのコミットをインタラクティブに編集
git rebase -i HEAD~3
# エディタで以下のように修正
# pick a1b2c3d コミットメッセージ1
# squash d4e5f6g コミットメッセージ2
# squash h7i8j9k コミットメッセージ3
# 保存して終了すると、コミットメッセージ編集画面が表示される
# 新しいコミットメッセージを入力
# 完了を確認
git log --oneline
例4:コミットメッセージを修正
# 最新のコミットメッセージを修正
git commit --amend -m "新しいコミットメッセージ"
# または、3つ前のコミットメッセージを修正
git rebase -i HEAD~3
# エディタで以下のように修正
# reword a1b2c3d コミットメッセージ1 (pick から reword に変更)
# pick d4e5f6g コミットメッセージ2
# pick h7i8j9k コミットメッセージ3
# 保存して終了すると、修正対象のコミットメッセージ編集画面が表示される
例5:コミットの順序を変更
# 3つのコミットの順序を変更
git rebase -i HEAD~3
# エディタで以下のように順序を並び替え
# pick d4e5f6g コミットメッセージ2 (2番目を1番目に)
# pick a1b2c3d コミットメッセージ1 (1番目を2番目に)
# pick h7i8j9k コミットメッセージ3
# 保存して終了
# 結果を確認
git log --oneline
第4章:Git rebaseのよくある間違い
間違い1:共有ブランチでrebaseを使用
問題点:
既にリモートリポジトリにプッシュされているブランチでrebaseを実行すると、他の開発者の作業と競合します。
悪い例:
# ❌ リモートにプッシュされているブランチで rebase
git rebase main
git push origin feature # これでエラーが発生
正しい方法:
個人専用のフィーチャーブランチのみでrebaseを使用します。本番環境やメインブランチではmergeを使います。
# ✅ 個人専用ブランチでのみ rebase を使用
git rebase main
# リモートにプッシュする際は -f (force) オプション使用(注意深く)
git push origin feature -f # force push は危険なため、通常は避ける
間違い2:rebase中にコマンドを誤解する
問題点:
インタラクティブrebaseで squash と fixup の違いを理解していないと、コミットメッセージが意図しない形になります。
悪い例:
# ❌ squash と fixup を混同
pick a1b2c3d コミット1
fixup d4e5f6g コミット2 # メッセージを保持したい場合
fixup h7i8j9k コミット3
正しい方法:
# ✅ 目的に応じて使い分け
pick a1b2c3d コミット1
squash d4e5f6g コミット2 # メッセージを保持したい場合
fixup h7i8j9k コミット3 # メッセージを破棄したい場合
間違い3:コンフリクト解決後にaddしない
問題点:
コンフリクトを解決してもファイルをステージングしないと、rebaseが進まないどころか、エラーが発生します。
悪い例:
# ❌ ファイルを編集したが add していない
git rebase develop # コンフリクト発生
# ファイルを編集
git rebase --continue # エラー: nothing to commit
正しい方法:
# ✅ 編集後は必ず add する
git rebase develop # コンフリクト発生
# ファイルを編集
git add ファイル名 # ステージングする
git rebase --continue # 成功
間違い4:rebaseをキャンセルする方法を知らない
問題点:
rebase中に問題が発生した場合、対処方法を知らないと混乱します。
正しい中止方法:
# rebase を中止して元の状態に戻す
git rebase --abort
# 既に --continue を実行してしまった場合は、git reflog で復旧
git reflog
git reset --hard HEAD@{n} # n は戻したいポイント
間違い5:プッシュ後のrebaseと強制プッシュ
問題点:
既にプッシュしたコミットをrebaseで修正する場合、通常のプッシュではできず、強制プッシュが必要になります。強制プッシュは他の開発者に迷惑がかかるため、危険です。
悪い例:
# ❌ 既にプッシュしたコミットを rebase して、無理にプッシュ
git rebase -i HEAD~3
git push origin feature -f # チームの他のメンバーに悪影響
正しい方法:
# ✅ rebase は個人専用ブランチでのみ行い、プッシュ前に完了させる
git rebase -i HEAD~3 # プッシュ前に実施
git push origin feature # 通常プッシュ
第5章:Git rebaseのベストプラクティス
rebaseを使うべき場面
1. ローカルブランチの整理
プッシュ前のローカルブランチなら、rebaseで履歴を整理することを推奨します。
2. 最新のメインブランチへの同期
featureブランチを常にmainの最新状態に保つため、rebaseが有効です。
3. プルリクエスト作成前の準備
プルリクエストを作成する際、コミット履歴が整理されていると、レビュアーにとって読みやすくなります。
mergeを使うべき場面
1. メインブランチへの統合
prodやmainブランチへの統合には、mergeを使用することが一般的です。
2. 公開されているブランチの更新
複数の開発者が使用しているブランチでは、mergeが安全です。
3. コミット履歴の完全な記録が必要な場合
金融やコンプライアンスが重要な業界では、mergeで全ての履歴を残します。
第6章:まとめ
Git rebaseは、Gitを効果的に使うための重要な機能です。正しく理解して使用することで、コミット履歴をきれいに保ち、チームの開発効率を向上させることができます。
重要なポイント:
- rebaseとは:ブランチの基準点(base)を変更し、コミット履歴を再構築する機能
- mergeとの違い:rebaseは線形な履歴を作り、mergeはツリー状の履歴を作る
- 基本的な使い方:
git rebase ブランチ名で別のブランチの最新状態をベースに設定 - インタラクティブrebase:
git rebase -i HEAD~nで複数のコミットを修正・統合 - コンフリクト解決:ファイルを編集して
git addし、git rebase --continue - 最重要注意点:共有ブランチではrebaseを使わない。個人専用ブランチで使用
- ベストプラクティス:プッシュ前のローカルブランチで履歴を整理することで、チーム全体の作業効率が向上
rebaseは最初は難しく感じるかもしれませんが、繰り返し使用することで習熟します。以下のステップで実践していくことをお勧めします:
- ローカルブランチで基本的なrebaseを試す
- コンフリクト解決の経験を積む
- インタラクティブrebaseでコミット履歴を整理する
- チームのワークフローに合わせたrebase/merge戦略を決める
Gitの学習を続けることで、効率的で安全なバージョン管理ができるようになります。このガイドが皆さんのGit習熟の助けになれば幸いです。

