📢

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

に公開
Git
rebase
merge
tech

前書き

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 を適切に使い分け、クリーンな履歴と効率的なコラボレーションを実現しましょう！

Discussion