Cherry-pick — その概要、メカニズム、Gitでの適用

Cherry-pickとは？

Cherry-pick は、指定されたコミットから変更をコピーし、現在のブランチに新しいコミットとして適用するGitコマンドです。名前は“チェリーピッキング”（さくらんぼ狩り）のメタファーに由来します。開発者は必要なコミットのみを選択し、残りは無視します。

Merge とは異なり、cherry-pickはマージコミットを作成せず、ブランチの完全なマージを必要としません。Rebase とは異なり、cherry-pickはコミットのシーケンスを転送せず、指定されたもののみを転送します。これにより、cherry-pickは修正の選択的転送に理想的なツールとなっています。

Atlassian、2025 によると、cherry-pickは複数のリリースブランチを同時に扱うチームの47%が使用しています。Cherry-pickは特にモバイル開発で需要があり、アプリケーションの複数バージョン（LTSリリース）が同時にメンテナンスされ、それらの間で修正を転送する必要があります。

転送メカニズム

Cherry-pickを実行すると、Gitは指定されたコミットとその親との間の差分を計算し、その差分を現在のブランチに適用します。変更が競合なく適用された場合、Gitは同じメッセージだが新しいSHAで新しいコミットを作成します。競合がある場合、cherry-pickは手動解決のために一時停止します。

Cherry-pickの仕組み

構文はシンプルです：転送するコミットのハッシュを指定します。Gitは変更を現在のブランチに新しいコミットとしてコピーします。一度に複数のコミットや範囲全体の転送がサポートされています。

# 現在のブランチに1つのコミットを転送
git cherry-pick a1b2c3d4

# 複数のコミットを転送
git cherry-pick a1b2c3d4 e5f6g7h8

# コミットの範囲を転送（a1b2からf9e8まで、a1b2を除く）
git cherry-pick a1b2c3d4..f9e8d7c6

Cherry-pick実行後、現在のブランチはソースからの変更を含む新しいコミットを取得します。コミットメッセージはデフォルトでソースからコピーされますが、-nフラグ（コミットを作成しない）または--edit（メッセージを編集）で変更できます。

修正転送の例

典型的なシナリオを考えてみましょう：developで重要なバグが発見され修正されました。このバグはリリースブランチrelease/v2.0にも存在します。develop全体をリリースブランチにマージせずに、この修正のみを転送する必要があります。

# developで修正のあるコミットハッシュを見つける
git log --oneline develop
# a1b2c3d fix: null check in payment processing

# リリースブランチに切り替える
git checkout release/v2.0

# 修正を適用する
git cherry-pick a1b2c3d4

# 競合がある場合 — 解決して続行
git add src/payment/PaymentProcessor.kt
git cherry-pick --continue

-x フラグは、コミットメッセージに元のSHAへの参照を追加します：“(cherry picked from commit a1b2c3d4)”。これにより、コミットがどこから転送されたかの追跡が容易になります。一時的なドラフトを除くすべてのシナリオで-xを使用することをお勧めします。

競合の解決

競合が発生した場合、cherry-pickはmergeのように動作します：Gitは停止し、競合するファイルをマークします。開発者は競合を解決し、git addを実行してからgit cherry-pick --continueを実行します。キャンセルするには — git cherry-pick --abort。--strategyフラグはマージ戦略（例えば、オプション付きのrecursive）を指定できます。

# Cherry-pick中の競合解決
# Gitが競合ファイルを表示
git status

# 手動で解決、その後：
git add 許可されたファイル.kt
git cherry-pick --continue

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

Cherry-pickを使用するタイミング

Cherry-pick は、ブランチ全体をマージせずに変更を選択的に転送する必要があるシナリオに最適です。Cherry-pickが最良の選択となる5つの主要なケースを見てみましょう。

• Hotfixの転送 — developで修正が見つかりましたが、リリースブランチ（release/v2.0）に適用する必要があります。Cherry-pickはdevelopの未完成機能に影響を与えずに修正コミットのみを転送します
• 古いバージョンへのバックポート — 現在のバージョンの修正をLTSリリースに転送する必要があります。現在のコードベース全体をマージする代わりに、cherry-pickは必要なコミットのみを選択します
• 誤ったブランチでのコミットの取り消し — コミットが誤ったブランチで行われた場合、cherry-pickはそれを正しいブランチに転送し、元のコミットは元に戻されます
• ドキュメントの転送 — すべてのブランチに存在すべきREADMEや設定ファイルの変更は、cherry-pickを介して転送すると便利です
• 選択的適用 — プロトタイプブランチから、プロトタイプ全体をメイン開発に転送せずに、成功した1つのコミットのみを取得する必要があります

モバイル開発では、アプリケーションの複数バージョンをサポートする際にcherry-pickが重要です。例えば、Google Playで既に公開されているバージョン3.2でバグが見つかり、developにバージョン4.0のコードが含まれている場合、cherry-pickはすべての破壊的変更をマージせずにv3.xブランチに修正を転送できます。これは、異なるAPIと依存関係を持つ2つ以上のメジャーバージョンを同時にメンテナンスするプロジェクトで特に重要です。

実践例：モバイルアプリでAndroid 12のGoogle Sign-In認証中にクラッシュが検出されました。修正はdevelopで行われ、コードレビューを通過しました。しかし、現在のリリースブランチv2.5は既にベータテスト段階にあります。Developからrelease/v2.5への修正コミットのCherry-pickにより、まだリリース準備ができていない他の変更を転送せずに、次のリリースに修正を含めることができます。

モバイルプロジェクトでcherry-pickを使用する際は、依存関係を考慮することが重要です：修正がリリースブランチの発散ポイント以降にdevelopで変更されたファイルに影響する場合、cherry-pickは不完全な変更セットをもたらす可能性があります。そのような場合、関連するすべての変更も転送されたことを確認する必要があります。そうしないと、アプリケーションがビルドできないか、正しく動作しない可能性があります。共有ブランチに変更をプッシュする前に、常にcherry-pick後にビルドを確認してください。

Cherry-pick vs Merge vs Rebase

Gitでの変更統合の3つの主要ツール — merge、rebase、cherry-pick — は異なるタスクを解決します。選択は、転送する変更の量と履歴の見た目に依存します。

Merge — 2つのブランチを完全にマージし、分岐情報を保持する必要がある場合。Rebase — クリーンな履歴で個人ブランチを最新の状態に更新する必要がある場合。Cherry-pick — 1つのコミットまたはいくつかの選択されたコミットのみが必要な場合。

実際には、これらのツールは組み合わせて使用されます：機能はdevelopへの定期的なrebaseで開発され、その後--no-ff mergeを介してマージされ、別のブランチに修正を転送する必要がある場合にcherry-pickが使用されます。各ツールはそれぞれの段階でそれぞれのタスクを解決します。

Cherry-pickのリスクと制限

Cherry-pick は便利ですが、誤用や過剰使用によって潜在的に危険なツールです。主なリスクは、コミットの重複、コンテキストの喪失、後続のマージ時の競合に関連しています。

• コミットの重複 — 同じコミットが後でmergeを介してブランチに入ると、Gitは変更において同一の2番目のコミットを作成します。これにより履歴が汚染され、git bisectが困難になります
• コンテキストの喪失 — cherry-pickは差分を転送しますが、親コミットや依存関係に関する情報は転送しません。Cherry-pickがコミットBなしで依存関係のあったコミットAを適用した場合、論理エラーが発生する可能性があります
• マージ競合 — cherry-pick後、ブランチの完全マージ中に、Gitが同じ変更を2回見て、通常のマージで回避できたはずの競合を作成する可能性があります
• トレーサビリティの欠如 — -xフラグがないと、コミットが別のブランチから転送されたことを知ることは不可能です。変更の起源を探す際、開発者はコミットの出所を特定するのに何時間も費やす可能性があります

リスク最小化の推奨事項：元のSHAを示すために常に-xフラグを使用し、コミットメッセージにcherry-pickの理由を文書化し、可能な場合はコンテキストが許す限りcherry-pickの代わりにmergeを使用してください。Cherry-pickが多くなった場合は、ブランチの再構築を検討してください。

Cherry-pickの自動チェック

CIパイプラインはcherry-pickを別のシナリオとして考慮する必要があります。自動チェックを設定することをお勧めします：cherry-pickコミットが作成されると、CIは変更されたファイルが期待されるセットと一致することを検証し、影響を受けるモジュールのテストを実行します。これにより、ブランチ間で変更を転送する際のリグレッションリスクが軽減されます。