Git rebaseとは?使い方から実践例までわかりやすく解説

Git

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で squashfixup の違いを理解していないと、コミットメッセージが意図しない形になります。

悪い例:

# ❌ 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は最初は難しく感じるかもしれませんが、繰り返し使用することで習熟します。以下のステップで実践していくことをお勧めします:

  1. ローカルブランチで基本的なrebaseを試す
  2. コンフリクト解決の経験を積む
  3. インタラクティブrebaseでコミット履歴を整理する
  4. チームのワークフローに合わせたrebase/merge戦略を決める

Gitの学習を続けることで、効率的で安全なバージョン管理ができるようになります。このガイドが皆さんのGit習熟の助けになれば幸いです。

タイトルとURLをコピーしました