Git rebase の使い方を、たくさんの実例で初心者にも分かりやすく解説してみた！

前書き

Git rebase って、使うのがちょっと怖いと思ったことありませんか？
Gitを使った開発の中で、rebaseコマンドは非常に強力ですが、「履歴が書き換えられる」「競合が増える」「チームメンバーに怒られた」など、怖い噂を聞いて敬遠している方も多いのではないでしょうか。

でも実は、Git rebaseを正しく理解すれば、mergeよりも履歴を綺麗に整理できたり、効率的に開発を進められる場面がたくさんあります。
この記事では、Git rebaseの基本から実践的な活用方法まで、初心者にもわかりやすく解説します。

また、git mergeと比較して、git rebaseを使用する上での注意点や、使いどころの判断基準についても触れます。
「怖いから使わない」ではなく、「安全に使いこなす」ための方法をこの記事でマスターしましょう！

基本概念：git rebase と git merge の違い

1. git merge

• 目的: ブランチを統合する。
• 特徴: 履歴を変更せず、統合時に「マージコミット」が作成される。
• 結果: 履歴が「分岐と統合」の形で残る。

2. git rebase

• 目的: 一つのブランチの変更を別のブランチの先頭に適用する。
• 特徴: 履歴を書き換えるため、より「直線的」な履歴を作成できる。
• 結果: 履歴が「一本の線」のように見える。

---

実例 1: チーム開発でのブランチの整理

シナリオ:

• あなたのチームでは、feature-A ブランチで新機能を開発中。
• しかし、その間に main ブランチが更新されてしまった。
• 今、自分の feature-A を main にマージする前に最新の状態に合わせたい。

解決方法: git rebase main

# 1. mainブランチを最新に更新
git checkout main
git pull origin main

# 2. feature-Aに移動
git checkout feature-A

# 3. rebaseを実行
git rebase main

効果:

• feature-A の変更が main の最新のコミットに適用されます。
• 履歴が「一本の線」になります。

比較: git merge を使った場合

git checkout feature-A
git merge main

• マージコミットが追加され、履歴が「分岐と統合」の形で残ります。

どちらを選ぶべき？

• merge: コミット履歴を完全に残したい場合。
• rebase: 履歴を整理してクリーンに保ちたい場合。

---

実例 2: コミットの整理

シナリオ:

• あなたのブランチには、開発中に行った細かいコミットがたくさんある。
• 他の人に共有する前に、これらを1つの意味のあるコミットにまとめたい。

解決方法: インタラクティブリベース

git checkout feature-A

# 過去3つのコミットを編集する
git rebase -i HEAD~3

エディタが開き、次のようなリストが表示されます：

pick abc123 First commit
pick def456 Second commit
pick ghi789 Third commit

pick を以下のように変更します：

pick abc123 First commit
squash def456 Second commit
squash ghi789 Third commit

結果、3つのコミットが1つにまとまります。

---

実例 3: フォークしたリポジトリを最新に保つ

シナリオ:

• オープンソースプロジェクトをフォークして、あなたのリポジトリで作業を進めている。
• オリジナルのリポジトリ（upstream）が更新されたので、それを取り込む必要がある。

解決方法: rebase

# 1. upstreamリモートを追加
git remote add upstream https://github.com/original/repo.git

# 2. upstreamの変更を取得
git fetch upstream

# 3. 自分のmainをupstreamのmainに合わせる
git checkout main
git rebase upstream/main

効果:

• オリジナルのリポジトリの変更を取り込む際に、クリーンな履歴を保てます。

---

実例 4: コンフリクトの解消

シナリオ:

• git rebase を実行中にコンフリクトが発生した。

解決方法:

1. コンフリクトを解消します。

# ファイルを編集してコンフリクトを解消
git add conflict-file.txt

1. リベースを続行：

git rebase --continue

1. 必要に応じて作業を中断：

git rebase --abort

---

実例 5: チームに迷惑をかけないリベース

ポイント:

• リベースは履歴を書き換えるため、共有されたブランチでリベースを行うと他の人に迷惑をかけることがあります。

ベストプラクティス:

• main や共有されているブランチではなく、自分のローカルブランチでのみリベースを使う。
• 既にプッシュした変更は、可能な限り merge を使う。

---

まとめ

1. git merge と git rebase の選択

   • 履歴を残したい場合：merge
   • クリーンな履歴が欲しい場合：rebase

2. git rebase の活用場面

   • 履歴を整理したいとき。
   • 最新のブランチに変更を適用したいとき。
   • コミットをまとめたいとき。

3. 注意点

   • リベースは履歴を書き換えるので慎重に使用する。
   • 共有ブランチではリベースしない。

開発現場では rebase と merge を適切に使い分け、クリーンな履歴と効率的なコラボレーションを実現しましょう！