前書き

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 を実行中にコンフリクトが発生した。

解決方法:

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

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

リベースを続行：

git rebase --continue

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

git rebase --abort

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

ポイント:

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

ベストプラクティス:

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

まとめ

git merge と git rebase の選択
- 履歴を残したい場合：merge
- クリーンな履歴が欲しい場合：rebase
git rebase の活用場面
- 履歴を整理したいとき。
- 最新のブランチに変更を適用したいとき。
- コミットをまとめたいとき。
注意点
- リベースは履歴を書き換えるので慎重に使用する。
- 共有ブランチではリベースしない。

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