Git Ready merge / rebase / cherry-pick の使い分け
3つのブランチ統合手段を場面ごとに使い分ける実践ガイド
3つのコマンドの役割
どれも「変更を取り込む」コマンドですが、履歴の残り方と影響範囲が異なります。
| コマンド | 役割 | 履歴 | 影響範囲 |
|---|---|---|---|
| merge（マージ） | ブランチの履歴を合流させる | マージコミットが残る（分岐が見える） | ブランチ全体 |
| rebase（リベース） | コミットを別のベースに付け替える | 直線的な履歴になる（分岐が消える） | ブランチ全体 |
| cherry-pick（チェリーピック） | 特定のコミットだけ別ブランチに持ってくる | 新しいコミットとしてコピーされる | 選んだコミットだけ |
基本は merge
迷ったら merge を使う
rebase と cherry-pick はコミットハッシュが変わる操作で、force push やチームの履歴不整合を引き起こすリスクがあります。特別な理由がなければ merge だけで十分です。詳しくは きれいな履歴にこだわりすぎない を参照してください。
merge を選ぶ場面
チームの共有ブランチ（main, develop）に機能ブランチを統合するときの基本手段です。
マージコミットが作られるため「いつ・どのブランチが統合されたか」が履歴に残ります。
Pull Request（プルリクエスト）のマージボタンも内部的には merge（または squash merge / スカッシュマージ）です。
迷ったら merge を使えば安全です。
# feature ブランチを main に統合（最も基本的なパターン）
git switch main
git merge feature/login
# マージコミットを必ず作る（fast-forward させない）
git merge --no-ff feature/login
# コミットをまとめて統合（squash merge）
git merge --squash feature/login
git commit -m "feature/login の変更を統合"rebase を選ぶ場面
自分の作業ブランチを main の最新に追従させたいときに使います。
merge と違いマージコミットが作られず、履歴が直線的になります。
Pull Request を出す前にコミットを整理する（interactive rebase / インタラクティブリベース）のも定番の使い方です。
ただし、プッシュ済みのコミットを rebase すると他の開発者に影響するため、ローカルの未プッシュコミットに対してのみ使うのが鉄則です。
# 作業ブランチを main の最新に追従させる
git switch feature/login
git fetch origin
git rebase origin/main
# PR 前にコミットを整理（squash / reword）
git rebase -i origin/main
# pull 時に rebase で統合（merge コミットを作らない）
git pull --rebase origin maincherry-pick を選ぶ場面
ブランチ全体ではなく、特定のコミットだけを別ブランチに適用したいときに使います。
典型例は「main で修正したバグフィックスをリリースブランチにも適用する」ケースです。
また、間違ったブランチにコミットしてしまった場合の救済にも使えます。
ただし多用するとコミットが重複し、後のマージでコンフリクトの原因になるため、本当に必要なときだけ使いましょう。
# main のバグ修正をリリースブランチにも適用
git switch release/v1.0
git cherry-pick abc1234
# 出所を記録する（チーム開発で推奨）
git cherry-pick -x abc1234
# 間違ったブランチのコミットを正しいブランチに移す
git switch correct-branch
git cherry-pick abc1234
git switch wrong-branch
git reset --hard HEAD~1判断フローチャート
ブランチ全体を統合したい?
→ merge か rebase。どちらか迷うなら次の質問へ。
履歴を直線にしたい & まだプッシュしていない?
→ rebase。ローカル未プッシュなら安全に使えます。
共有ブランチへの統合、またはプッシュ済み?
→ merge。マージコミットで統合履歴が残り、他の開発者への影響もありません。
特定のコミットだけ持ってきたい?
→ cherry-pick。範囲を絞って取り込めます。
迷ったら merge を選ぶのが最も安全です。
チームでのルール例
多くのチームが採用しているルールの一例です。
「main への統合は PR 経由の merge（--no-ff）」「作業ブランチの更新は rebase」「リリースブランチへのホットフィックスは cherry-pick -x」。
チームで合意したルールを README や CONTRIBUTING.md に書いておくと混乱を防げます。
# チームでよくある運用フロー
# 1. 機能開発中: rebase で main に追従
git switch feature/new-feature
git fetch origin
git rebase origin/main
# 2. PR マージ: merge --no-ff で統合
git switch main
git merge --no-ff feature/new-feature
# 3. ホットフィックス: cherry-pick で展開
git switch release/v2.0
git cherry-pick -x <hotfix-commit-hash>