もう迷わない!Gitのマージ・リベースの選び方

開発中Gitを使っていると、以下のような疑問で悩んだことはありませんか?

  • Fast-forwardって何?普通のマージとどう違うの?
  • rebaseって何のために使うの?
  • 結局どれを使えばいいの?

この記事では、Gitでのブランチ統合の種類と、実務での正しい使い分けについて解説します。

まずは3つの統合方法を理解しよう

1. Fast-forwardマージ

gitGraph
    commit id: "main-1"
    branch feature
    commit id: "feat-1"
    commit id: "feat-2"
    checkout main
    merge feature

特徴

  • 履歴が一直線になる
  • ブランチの分岐が残らない
  • マージコミットが作られない
  • コマンド: git merge feature(Fast-forward可能な場合)

いつ使うの?

  • 主ブランチに新しい変更がない場合
  • シンプルな履歴を保ちたい場合

2. 通常のマージ(マージコミット)

gitGraph
    commit id: "main-1"
    branch feature
    commit id: "feat-1"
    checkout main
    commit id: "main-2"
    merge feature

特徴

  • ブランチの分岐が履歴に残る
  • マージコミットが作成される
  • 両方のブランチの履歴が保持される
  • コマンド: git merge feature(Fast-forward不可能な場合)または git merge --no-ff feature

いつ使うの?

  • 機能の統合ポイントを明確にしたい場合
  • レビューやロールバックを考慮する場合

3. リベース(rebase)

gitGraph
    commit id: "main-1"
    commit id: "main-2"
    branch feature
    commit id: "feat-1"
    commit id: "feat-2"
    checkout feature
    commit id: "After rebase"

特徴

  • コミット履歴が一直線になる
  • コミットのハッシュが変更される
  • ブランチの作業を移し替える
  • コマンド: git rebase main(featureブランチ上で実行)

いつ使うの?

  • クリーンな履歴を維持したい場合
  • 他の開発者の変更を取り込む場合
  • ※共有ブランチでは使用注意

具体的な例で理解を深めよう

シナリオ1: シンプルな機能追加

# featureブランチを作成
git checkout -b feature
# 作業を実施...
git commit -m "Add new feature"
# mainブランチに戻る
git checkout main
# Fast-forwardマージ
git merge feature  # 自動的にFast-forwardされる

シナリオ2: 並行開発での統合

# featureブランチで作業中
git checkout feature
git commit -m "Update feature"
# mainブランチにも別の変更が入った場合
git checkout main
git merge feature  # マージコミットが作成される

シナリオ3: リベースを使った統合

# featureブランチで作業中
git checkout feature
# mainの変更を取り込む
git rebase main
# その後必要に応じてマージ
git checkout main
git merge feature  # Fast-forwardされる

選び方の基本方針

  1. 基本は通常のマージ
    • 安全で分かりやすい
    • チーム開発で推奨
    • 履歴が追跡しやすい
  2. Fast-forwardが可能な場合
    • そのままFast-forwardを許可
    • 履歴がシンプルになる
    • 特に問題なければこれでOK
  3. リベースの使用
    • 個人の作業ブランチで使用
    • きれいな履歴が必要な場合
    • チームの合意がある場合

重要な注意点

リベース使用時の注意

  • 公開済みブランチでは使用しない
  • 履歴が書き換わることを理解する
  • コンフリクト解決が必要になることも

マージコミット作成時の注意

  • 適切なコミットメッセージを書く
  • 統合の理由や内容を明記する
  • レビューアのことを考慮する

よくある疑問

リベースとマージ、どちらが良いですか?
チームの方針に従いましょう。基本はマージから始めることをお勧めします。
リベースは怖いという話を聞きましたが?
公開ブランチでの使用を避け、個人作業用ブランチでのみ使用すれば安全です。
Fast-forwardとリベース、何が違うの?
Fast-forwardは単純な追従、リベースは履歴の再構築です。リベースの方が侵襲的な操作になります。

まとめ:これだけ覚えておこう!

  1. 基本は通常のマージを使う
  2. Fast-forwardができる場合は許可する
  3. リベースは個人作業ブランチでのみ使用
  4. チームの方針がある場合はそれに従う

GitKrakenでのPull操作の種類と使い分け

GitKrakenでPullを行う際、以下の3つの選択肢が表示されます:

1. Pull (Fast-forward if possible)

  • 動作: 可能な場合はFast-forwardで、できない場合はマージコミットを作成
  • コマンド相当: git pull (通常のpull)
  • 使うべき時:
    • 通常の開発作業全般
    • チーム開発での標準的な選択肢
    • 特に理由がない限りこちらを選択
  • メリット:
    • 最も柔軟な方法
    • 安全な操作
    • トラブルが少ない

2. Pull (Fast-forward only)

  • 動作: Fast-forwardでの統合のみを許可し、それ以外は失敗
  • コマンド相当: git pull --ff-only
  • 使うべき時:
    • ローカルに独自の変更がない場合
    • 確実にクリーンな履歴を維持したい場合
    • 意図しないマージを防ぎたい場合
  • 注意点:
    • ローカルに未pushのコミットがあると失敗
    • 履歴が分岐している場合は手動での対応が必要

3. Pull (Rebase)

  • 動作: ローカルの変更をリモートの変更の上に移動
  • コマンド相当: git pull --rebase
  • 使うべき時:
    • きれいな一直線の履歴にしたい場合
    • 個人の作業ブランチでの作業時
    • チームでrebaseを使用する方針の場合
  • 注意点:
    • 共有ブランチでは使用を避ける
    • コミットハッシュが変更される
    • コンフリクト解決が必要になることがある