Git を使っていると 「merge と cherry-pick、どちらを使うべきか？」 で迷う場面は少なくありません。
特に複数ブランチ間で修正をやり取りするプロジェクトでは、両者の使い分けがトラブル防止につながります。
この記事では 特徴・履歴上の違い・使い分けポイント をまとめました。
1. そもそも merge と cherry-pick とは？
merge
あるブランチの 変更履歴（コミット群）を現在のブランチへ統合 する操作。共通祖先を基に差分を計算し、必要なら マージコミット が作成されます。
# 例：feature/login-fix を develop へ取り込む
git checkout develop
git merge feature/login-fix
cherry-pick
特定コミットだけを現在のブランチへ「摘み取って」適用 する操作。同一内容でも 新しいコミット として記録され、コミット ID は変わります。
# 例：コミット abc1234 を develop へ適用
git checkout develop
git cherry-pick abc1234
📚 公式ドキュメント: https://git-scm.com/docs/git-cherry-pick
“Apply the changes introduced by some existing commits.” — 既存コミットの変更を 新しいコミット として適用すると明記されています。
2. コミット履歴上の違い
| 操作 | 履歴の特徴 | コミット ID | 影響範囲 |
|---|---|---|---|
| merge | 履歴が 1 本にまとまる | 元 ID を保持 | ブランチ全体の変更を統合 |
| cherry-pick | 履歴が分岐しやすい | 異なる ID に変化 | 指定コミットだけを適用 |
Git のコミット ID は「親 ID・作者・日時・内容」すべて をハッシュ化して生成されるため、
cherry-pickされたコミットは見た目が同じでも 別物 になります。
3. コンフリクト発生の傾向
merge
- 3‑way マージで共通祖先を参照するため、重複修正は自動解決されることも
cherry-pick
- 単独差分を貼り付けるだけなので、同じ修正が既に含まれていても Git は 別変更 と判断
- 後の merge で ダブル適用 となり、コンフリクト要因になりがち
4. 使い分けのポイント
| シチュエーション | 適切な選択 | 理由 |
|---|---|---|
| ブランチ全体を統合したい | merge | 履歴を保ちつつ一括取り込み |
| 一部の修正だけ反映したい | cherry-pick | 必要なコミットだけ摘み取れる |
| 今後もブランチ間で同期予定 | merge | 重複によるコンフリクトを抑制 |
| 緊急 Hotfix を横展開 | cherry-pick | 最小限の修正を素早く各環境へ |
5. よくある誤解：「cherry-pick なら元コミットと同じになる？」
なりません！
前述の通り Git のコミット ID はメタデータ込みで生成されるため、
cherry-pick した時点で 必ず別 ID になります。
これは「どこから来た修正か」を追跡できる Git の信頼性の核でもあります。
6. 結論
merge
-
履歴を正規に “つなぐ” 手段
-
今後も相互にマージするブランチ同士ならこちらが安全
cherry-pick
- 単発修正の横展開に便利
- ただし履歴が分岐・重複しやすく、将来的なコンフリクト要注意
双方向で継続同期なら merge、一方向の一発適用なら cherry-pick が目安。
Git は自由度が高い分、チーム運用ルールを明確にして履歴の混乱を防ぎましょう。
以上、参考になれば嬉しいです！