開発中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される
選び方の基本方針
- 基本は通常のマージ
- 安全で分かりやすい
- チーム開発で推奨
- 履歴が追跡しやすい
- Fast-forwardが可能な場合
- そのままFast-forwardを許可
- 履歴がシンプルになる
- 特に問題なければこれでOK
- リベースの使用
- 個人の作業ブランチで使用
- きれいな履歴が必要な場合
- チームの合意がある場合
重要な注意点
リベース使用時の注意
- 公開済みブランチでは使用しない
- 履歴が書き換わることを理解する
- コンフリクト解決が必要になることも
マージコミット作成時の注意
- 適切なコミットメッセージを書く
- 統合の理由や内容を明記する
- レビューアのことを考慮する
よくある疑問
- リベースとマージ、どちらが良いですか?
- チームの方針に従いましょう。基本はマージから始めることをお勧めします。
- リベースは怖いという話を聞きましたが?
- 公開ブランチでの使用を避け、個人作業用ブランチでのみ使用すれば安全です。
- Fast-forwardとリベース、何が違うの?
- Fast-forwardは単純な追従、リベースは履歴の再構築です。リベースの方が侵襲的な操作になります。
まとめ:これだけ覚えておこう!
- 基本は通常のマージを使う
- Fast-forwardができる場合は許可する
- リベースは個人作業ブランチでのみ使用
- チームの方針がある場合はそれに従う
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を使用する方針の場合
- 注意点:
- 共有ブランチでは使用を避ける
- コミットハッシュが変更される
- コンフリクト解決が必要になることがある