【完全ガイド】git cherry-pick の使い方｜単一・範囲・マージコミット・conflictまで徹底解説

Git を使いこなす上級者になるための必修コマンドの一つが cherry-pick:

# 別ブランチの特定コミットだけを、今のブランチに適用
git cherry-pick abc1234

まさに「桜の実（cherry）を摘む（pick）」ように、特定のコミットだけを選んで別のブランチに移植する強力な機能。

現場では:

• バグ修正だけを本番ブランチに適用したい（hotfix）
• 開発中の feature の一部だけを別ブランチへ（backport）
• リリース済みの安定版に、必要な修正だけを適用
• 消してしまったコミットを別ブランチから復元
• feature ブランチを部分的にmergeしたい

こんな時に活躍する、まさに外科手術のような精密さを持つコマンドです。

しかし、実際に使い始めると:

• 単一コミットは分かるが範囲指定の書き方が分からない
• マージコミット の cherry-pick でハマる
• conflict 発生時の対処が謎
• -x オプションって何？
• --no-commit は何が便利？
• 重複コミット問題が発生する
• rebase / merge との使い分けが曖昧

など、意外と奥深く、正しく理解しないと履歴を破綻させるリスクも。

本記事では、git cherry-pick の完全な使い方を、リファレンスとして実用的に整理します。基本構文、単一/複数/範囲指定、主要オプション（-e / -n / -x / -s / -X）、マージコミット（-m）、conflict 対応、cherry-pick vs merge vs rebase の比較、実践パターン（backport・hotfix）、落とし穴と予防策、Rails / Kamal 開発への活用、FAQまで完全網羅。この1本で cherry-pick を外科手術のように正確に使いこなせるようになります。

結論：3秒で理解する使い方

時間がない方向けに、最重要ポイントを先に示します。

基本コマンド

# 単一コミット
git cherry-pick abc1234

# 複数コミット（順番に）
git cherry-pick abc1234 def5678

# 範囲（開始は含まない、終了は含む）
git cherry-pick abc1234..ghi9012

# 範囲（開始も含む）
git cherry-pick abc1234^..ghi9012

主要オプション

# メッセージ編集
git cherry-pick -e abc1234

# commit せずに変更だけ適用（プレビュー）
git cherry-pick -n abc1234

# 元コミットへの参照を追加
git cherry-pick -x abc1234

# マージコミットを cherry-pick
git cherry-pick -m 1 <merge-hash>

conflict 対応

# 解決してcontinue
git add resolved-file
git cherry-pick --continue

# スキップ
git cherry-pick --skip

# 中止
git cherry-pick --abort

使うべき場面 / 避ける場面

✅ 使うべき:

• hotfix（本番ブランチへの緊急バグ修正の移植）
• backport（新ブランチから古いブランチへ）
• 個別コミットだけの選択的適用

❌ 避けるべき:

• 頻繁に merge されるブランチ間（重複コミット問題）
• 大量のコミットの一括移動（rebase / merge の方が適切）

詳細は以下で解説します。

まず理解する：cherry-pick とは何か

基本の仕組み

Before:
main:     A ─ B ─ C
                    
feature:      X ─ Y ─ Z

git cherry-pick Y の後:
main:     A ─ B ─ C ─ Y'  ← Y と同じ内容の新コミット
                    
feature:      X ─ Y ─ Z

元のコミット Y は残ったまま、Y と同じ変更を持つ新しいコミット Y’ が現在のブランチに作られます。

重要：新しいコミット SHA が作られる

• 元: abc1234
• cherry-pick 後: xyz9876（別のハッシュ）

内容は同じでも、別のコミットとして扱われる。この特性が両刃の剣。

merge との違い

merge feature:
main:     A ─ B ─ C ─ M
                    /
feature:  X ─ Y ─ Z

→ feature の全コミット (X, Y, Z) が入る

cherry-pick Y:
main:     A ─ B ─ C ─ Y'
                    
feature:  X ─ Y ─ Z

→ Y だけが入る

merge は全部、cherry-pick は選択的。

rebase との違い

rebase main (feature 側で実行):
main:     A ─ B ─ C
                    \
feature:             X' ─ Y' ─ Z'

→ 自分のコミット全部が main の上に載る

rebase は「自分のブランチの全コミットを移動」、cherry-pick は「他のブランチの特定コミットだけを持ってくる」。

基本の cherry-pick

単一コミット

git cherry-pick <commit-hash>

例:

# feature ブランチのバグ修正コミットを main に持ってくる
git checkout main
git cherry-pick abc1234

複数コミット（順番に）

git cherry-pick abc1234 def5678 ghi9012

• 左から順に適用
• 各コミットで個別に conflict の可能性

範囲指定：A..B（A を含まない）

git cherry-pick A..B

A の次のコミットから B までを適用（A は含まない）。

例:

コミット順: X ← Y ← Z ← W

git cherry-pick Y..W
# Y は含まない、Z, W が適用される

範囲指定：A^..B（A を含む）

git cherry-pick A^..B

A から B まで全部を適用（A も含む）。

例:

コミット順: X ← Y ← Z ← W

git cherry-pick Y^..W
# Y, Z, W が適用される

ブランチ名も指定可能

# main ブランチの最新コミットを適用
git cherry-pick main

# feature ブランチの最新から3個前まで
git cherry-pick feature~2..feature

主要オプション

-e / --edit：メッセージ編集

git cherry-pick -e abc1234

• 適用前にエディタが開く
• メッセージを書き直せる
• 「Backport: …」のようなプレフィックス追加に便利

-n / --no-commit：commit せずに変更だけ

git cherry-pick -n abc1234

動作:

• 変更を working tree と index に適用
• commit は作らない
• 手動で commit するか、他の変更と合わせて commit 可能

用途:

• プレビュー: 変更内容を確認してから commit
• 複数コミットの統合: 複数の cherry-pick を1つの commit に
• メッセージのカスタマイズ

# 2つのコミットを1つの commit に統合
git cherry-pick -n abc1234
git cherry-pick -n def5678
git status  # 両方の変更が staged
git commit -m "Combined: Backport bug fix + feature toggle"

-x：元コミット参照を追加

git cherry-pick -x abc1234

コミットメッセージに自動的に元コミット参照が追加:

Fix critical bug in payment flow

(cherry picked from commit abc1234567890abcdef)

用途:

• backport の履歴を明確化
• 「これはどこから来たか」がすぐわかる
• 公開ブランチ（release など）への backport に特に有用

⚠️ プライベートブランチ間の cherry-pick では不要（情報が受け手に無意味）。

-s / --signoff：Signed-off-by 追加

git cherry-pick -s abc1234

コミットメッセージに:

Signed-off-by: Your Name <your@email.com>

を追加。Linux Kernel などのプロジェクトで慣習。

-S / --gpg-sign：GPG 署名

git cherry-pick -S abc1234
# または
git cherry-pick -S=<keyid> abc1234

GPG で署名した commit を作成。セキュリティ重視のプロジェクト向け。

-X <strategy-option>：マージ戦略オプション

# ours: conflict時に自分側優先
git cherry-pick -X ours abc1234

# theirs: conflict時に相手側優先
git cherry-pick -X theirs abc1234

# patience: より慎重なマッチング
git cherry-pick -X patience abc1234

詳細はgit merge conflict の解決方法の記事も参照。

--strategy=<strategy>：マージ戦略

# デフォルトの ort
git cherry-pick --strategy=ort abc1234

# recursive（レガシー、Git 2.34以前）
git cherry-pick --strategy=recursive abc1234

通常は指定不要。デフォルトで最適な戦略。

--ff：Fast-forward 可能なら適用のみ

git cherry-pick --ff abc1234

コミット構造が単純な場合、新規コミットを作らず HEAD だけ進める。用途は限定的。

--allow-empty：空コミットも許可

git cherry-pick --allow-empty abc1234

対象コミットに変更がない場合、通常はエラー。--allow-empty で許可。

--allow-empty-message：空メッセージ許可

git cherry-pick --allow-empty-message abc1234

--keep-redundant-commits：重複でも commit

適用しても変更ゼロになるケースでも commit を作成。

Conflict 対応

発生パターン

git cherry-pick abc1234
# error: could not apply abc1234... Fix critical bug
# hint: after resolving the conflicts, mark the corrected paths
# hint: with 'git add <paths>' or 'git rm <paths>'
# hint: and commit the result with 'git cherry-pick --continue'

解決フロー

# 1. 状況確認
git status

# 2. conflict ファイル編集
vim src/config.js
# <<<<<<< HEAD ~ >>>>>>> のマーカーを消して正しい状態に

# 3. マーク
git add src/config.js

# 4. 続行
git cherry-pick --continue

詳細はgit merge conflict の解決方法の記事も参照。

中止する

git cherry-pick --abort
# cherry-pick 開始前の状態に戻る

安全な脱出口。何かおかしいと思ったら abort。

スキップする

git cherry-pick --skip
# このコミットは飛ばして、次のコミットに進む

複数コミットの範囲指定で、途中の1個だけ問題がある時に便利:

git cherry-pick abc1234 def5678 ghi9012
# def5678 で conflict

# def5678 だけスキップ
git cherry-pick --skip
# → ghi9012 の適用に進む

状態を忘れる（–quit）

git cherry-pick --quit
# cherry-pick の状態を忘れる（ファイル変更は残る）

--abort と違い、working tree の変更は保持。稀な用途。

状態確認

# 現在の cherry-pick 状態
cat .git/CHERRY_PICK_HEAD
# → cherry-pick 中のcommit hash

# 実行中のシーケンス
cat .git/sequencer/todo

マージコミットの cherry-pick（-m）

通常のマージコミットは cherry-pick できません:

git cherry-pick <merge-hash>
# error: commit <merge-hash> is a merge but no -m option was given.

理由：マージコミットには親が2つあるため、「どちらの側の変更を持ってくる？」が Git に分からない。

-m オプション

git cherry-pick -m 1 <merge-hash>
# 第1親（main側）の変更を適用

git cherry-pick -m 2 <merge-hash>
# 第2親（feature側）の変更を適用

親番号の意味

main:      A ─ B ─ C ─ M
                     /
feature:            X ─ Y

M の親:
- 第1親: C (main側)
- 第2親: Y (feature側)

通常は -m 1（main側）で「feature の変更を取り込む形」を再現。

注意点

• マージコミットの cherry-pick は複雑
• 再度 merge するとおかしくなる可能性
• 可能なら個別コミットを cherry-pick推奨

実践シナリオ

シナリオ1：hotfix の適用

状況: main に緊急バグ修正、release ブランチにも適用したい。

# main で修正
git checkout main
vim src/critical.js
git commit -am "Fix critical login bug"
git push

# release-1.0 に backport
git checkout release-1.0
git cherry-pick -x main
# → release-1.0 に修正が適用される
# → メッセージに元コミット参照付き

git push origin release-1.0

シナリオ2：feature の一部だけ移植

状況: feature-big で開発中の3コミットのうち、便利な2つだけ main へ。

git log feature-big --oneline
# abc1234 Add ambitious redesign（不採用）
# def5678 Add useful utility
# ghi9012 Fix common typo

# main で 2 つだけ適用
git checkout main
git cherry-pick def5678 ghi9012
git push

シナリオ3：削除したコミットの復元

状況: reset –hard で消してしまったコミットを復元したい。

# reflog で消えたコミットを探す
git reflog
# HEAD@{5}: commit: Important work

# cherry-pick で復元
git cherry-pick HEAD@{5}

詳細はgit reset vs revert vs restore の記事も参照。

シナリオ4：範囲指定でまとめて適用

状況: feature の作業を release ブランチにまとめて。

git log feature --oneline
# ghi9012 Latest
# def5678 Middle
# abc1234 First
# zzz9999 Base (already in release)

# abc1234 から ghi9012 まで全部
git checkout release
git cherry-pick abc1234^..ghi9012

シナリオ5：commit しないで適用（-n）

状況: 2つの feature ブランチの変更を統合して1つの commit に。

git checkout main

# 2つ選択的に適用（commit なし）
git cherry-pick -n feature-a
git cherry-pick -n feature-b

# 手動で調整
vim src/combined.js
git add -A

# 1つのcommit に
git commit -m "Combine features A and B with adjustments"

シナリオ6：CI/CD の hotfix プロセス

# .github/workflows/cherry-pick-hotfix.yml
name: Cherry-pick hotfix

on:
  pull_request:
    types: [closed]
    branches: [main]

jobs:
  cherry-pick:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Cherry-pick to release
        run: |
          git checkout release
          git cherry-pick -x ${{ github.event.pull_request.merge_commit_sha }}
          git push

シナリオ7：Rails マイグレーションの hotfix

状況: 本番でDBエラー、feature ブランチにある修正migrationを緊急適用。

# feature の修正 commit
git log feature --oneline
# abc1234 Add index to fix N+1

# main に cherry-pick
git checkout main
git cherry-pick abc1234

# migration 実行
bin/rails db:migrate

# デプロイ
git push
kamal deploy

詳細はrails db:migrate 使い方の記事、Kamal 2 デプロイの記事、MySQL EXPLAIN 見方の記事も参照。

シナリオ8：長期分岐した release ブランチへの backport

状況: 数ヶ月前の release ブランチに、最新の脆弱性修正を適用。

git checkout main
git log --oneline | head
# ✅ abc1234 Fix XSS vulnerability

# release-3.0 に backport
git checkout release-3.0
git cherry-pick -x abc1234

# conflict 大量発生の可能性
# → 慎重に解決 or --patience 戦略
git cherry-pick --abort
git cherry-pick -x -X patience abc1234

シナリオ9：Solid Queue の bug fix backport

# main で修正
git log --oneline
# def5678 Fix Solid Queue race condition

# 古い release に適用
git checkout release-1.5
git cherry-pick -x def5678

詳細はSolid Queue 使い方の記事、Solid Cache 使い方の記事も参照。

シナリオ10：Docker Compose 設定の共有

# feature-docker ブランチで Docker Compose 更新
git log --oneline
# abc1234 Update docker-compose.yml for Rails 8

# main へ持ってくる
git checkout main
git cherry-pick abc1234

詳細はdocker daemon 接続エラーの記事も参照。

cherry-pick vs 他コマンド 比較

cherry-pick vs merge

cherry-pick vs rebase

詳細はgit rebase 使い方の記事も参照。

cherry-pick vs revert

詳細はgit reset vs revert vs restore の記事も参照。

使い分けフロー

質問: 他ブランチの何が欲しい？

├─ 全部 → merge
├─ 全部（線形履歴で） → rebase
├─ 一部だけ → cherry-pick
└─ 特定コミットを打ち消し → revert

落とし穴と予防策

落とし穴1：重複コミット

問題: cherry-pick 後、後で merge すると同じ変更が2度入る。

main:    A ─ B ─ C ─ Y'（cherry-picked）
                    /
feature: X ─ Y ─ Z（Y が元）

# 後で feature を main に merge
git merge feature
# → Y' と Y の両方が存在、重複

対策:

• cherry-pick する場合、そのブランチは後で merge しない
• または、rebase で対応することを検討

落とし穴2：Author と Committer

cherry-pick は元の author を保持、committer は自分:

git log -1
# Author: Original Author <original@example.com>
# Commit: You <you@example.com>

author を自分にしたい場合:

git cherry-pick -n abc1234
git commit --reset-author -C abc1234

落とし穴3：長期分岐での cherry-pick 失敗

長期間分岐したブランチへの cherry-pick は conflict 頻発:

# 数ヶ月前のブランチに cherry-pick
git cherry-pick abc1234
# → 大量の conflict

対策:

• -X patience 戦略で慎重に
• 手動で patch を再構築（git format-patch）
• 諦めて手動で修正を再実装

落とし穴4：マージコミット問題

git cherry-pick <merge-hash>
# error: is a merge but no -m option

対処:

• -m で親を指定
• または、マージ元の個別コミットを cherry-pick

予防策

1. -x で元コミット参照を残す（backport 時）
2. cherry-pick は最小限に（重複回避）
3. 範囲指定は A^..B の意味を理解して
4. conflict 時は焦らず --abort で戻れる
5. チームで cherry-pick ポリシーを共有

トラブルシューティング

cherry-pick が終わらない

git status
# You are currently cherry-picking commit abc1234

対処:

# 解決してcontinue
git cherry-pick --continue

# または中止
git cherry-pick --abort

git status が「nothing to commit」なのに continue できない

すでに解決済みの状態:

git cherry-pick --continue
# → 変更なし → 空commitでもいい？と聞かれるか、エラー

# 空commit を許可
git cherry-pick --continue --allow-empty

「fatal: commit is a merge but no -m option」

git cherry-pick <merge-hash>
# → -m 必要

対処:

git cherry-pick -m 1 <merge-hash>

空 commit になる

対象コミットの変更が既に適用されている:

git cherry-pick abc1234
# The previous cherry-pick is now empty, possibly due to conflict resolution.

対処:

# スキップ
git cherry-pick --skip

# または空commit を許可
git cherry-pick --allow-empty

author が意図と違う

# author を自分に
git commit --amend --reset-author

cherry-pick 後の push が rejected

git push origin main
# ! [rejected] 

→ 通常の push rejected と同じ:

git pull --rebase origin main
git push

詳細はgit push rejected の記事も参照。

よくある質問（FAQ）

Q1. cherry-pick と rebase、どっちを使う？

• 他ブランチの1〜数個のコミットが欲しい → cherry-pick
• 自ブランチの多数コミットを別ベースに → rebase

Q2. -x は常に付けるべき？

• 公開ブランチ間の backport → 付ける（元コミット追跡可）
• プライベート開発 → 不要

Q3. A..B と A^..B の違い

• A..B: A を含まない（B までの新規コミット）
• A^..B: A を含む（A から B まで全部）

Q4. 複数コミットの範囲、大量にある場合

# 全部でも問題ない
git cherry-pick abc1234^..ghi9012

ただし conflict が多い場合、個別に cherry-pick + --skip 併用の方が管理しやすい。

Q5. cherry-pick 後の元コミットを削除したい

しない。cherry-pick は元コミットに影響しない。もし元も削除したいなら別途 git reset / git rebase -i で削除。

Q6. cherry-pick vs merge –squash

• cherry-pick: 個別コミットを維持
• merge –squash: 全部を1コミットに集約

用途が違う。

Q7. cherry-pick を undo したい

# 直後なら
git reset --hard HEAD^

# push 済みなら
git revert <cherry-picked-hash>

詳細はgit reset vs revert vs restore の記事も参照。

Q8. GitHub Actions で自動 cherry-pick

- name: Cherry-pick to backport-branch
  run: |
    git config user.email "actions@github.com"
    git config user.name "GitHub Actions"
    git checkout backport-branch
    git cherry-pick -x ${{ github.event.pull_request.merge_commit_sha }}
    git push

Q9. rerere との連携

git config --global rerere.enabled true

同じ conflict を何度も解決する必要が減る。詳細はgit rebase 使い方の記事、git merge conflict の記事も参照。

Q10. Fork リポジトリからの cherry-pick

# fork のremote 追加
git remote add fork https://github.com/user/fork.git
git fetch fork

# fork の特定コミットを cherry-pick
git cherry-pick fork/branch~2

Q11. IDE / GUI での cherry-pick

• VS Code: GitLens 拡張で対応
• SourceTree: 右クリック → Cherry Pick
• GitKraken: ドラッグ&ドロップ対応

CLI で対応してから GUI 使用が確実。

Q12. cherry-pick でエラー「your local changes would be overwritten」

未commit の変更あり:

git stash push -u -m "before cherry-pick"
git cherry-pick abc1234
git stash pop

詳細はgit stash 使い方の記事、Your local changes would be overwritten by merge の記事も参照。

参考リンク・関連資料

Git 公式

• git-cherry-pick Documentation – cherry-pick 公式
• Pro Git Book – Git 完全ガイド

まとめ

git cherry-pick の使い方、要点を再整理します。

基本構文

# 単一
git cherry-pick abc1234

# 複数
git cherry-pick abc1234 def5678

# 範囲（A 含まない）
git cherry-pick A..B

# 範囲（A 含む）
git cherry-pick A^..B

主要オプション

Conflict 対応

git cherry-pick --continue    # 解決してcontinue
git cherry-pick --skip        # スキップ
git cherry-pick --abort       # 中止
git cherry-pick --quit        # 状態忘れる

使い分け

実践パターン

• hotfix: main で修正 → release に cherry-pick -x
• backport: 新ブランチから古いブランチへ
• 選択的統合: feature の一部だけ
• 削除復元: reflog + cherry-pick
• 統合: -n で複数を1コミットに

落とし穴

• 重複コミット: cherry-pick したブランチを後で merge すると重複
• マージコミット: -m 必須
• author 保持: 元の author が残る（--reset-author で変更可）
• 長期分岐: conflict 頻発 → 慎重に

予防策

• -x で元コミット参照を残す
• 重複を避けるためのポリシー
• conflict 時は --abort で戻れる
• --no-commit でプレビュー

これらの知識は、日常の Git 操作・hotfix 対応・backport・チーム開発・オープンソースコントリビュートなど、あらゆる場面で活用できます。本記事をブックマークしておけば、cherry-pick を外科手術のように正確に使いこなせるようになります。

本記事は2026年6月時点の情報をもとに、Git 2.40+ での動作確認・公式ドキュメントに基づき作成しています。Git のバージョンによって挙動が異なる場合があるため、最新の情報はGit公式ドキュメントもあわせてご確認ください。