git cherry-pickで特定コミットを別ブランチに移動する実践手法

本記事では、git cherry-pickを使って特定のコミットを別のブランチに効率的に移動・適用する方法を解説します。 機能ブランチから本番環境へのホットフィックス適用、複数ブランチ間での選別的なコミット取り込みなど、実務で頻繁に発生するシーンで即座に活用できる技法を習得できます。

git cherry-pickとは何か

git cherry-pickは、特定のコミットを現在のブランチに適用するGitコマンドです。 ブランチ全体をマージするのではなく、選別した個別のコミットだけを取り込みたい場合に非常に有用です。

通常のマージ(git merge)では、2つのブランチ全体の履歴が統合されますが、 cherry-pickを使うと、指定したコミットのみを現在作業中のブランチに「移植」できます。

基本的な使い方:単一コミットの移動

最もシンプルなパターン

別ブランチの特定コミットを現在のブランチに適用するには、以下のコマンドを実行します。

git cherry-pick <commit-hash>

実際の例を見てみましょう。

# 現在のブランチを確認
git branch
# 出力: * main
#         feature-branch

# feature-branchのコミット履歴を確認
git log feature-branch --oneline
# 出力: abc1234 ユーザー認証機能の修正
#        def5678 ログイン画面のUIバグ修正
#        ghi9012 パスワード検証ロジック改善

# main ブランチに「ログイン画面のUIバグ修正」を適用したい場合
git cherry-pick def5678

# 結果をログで確認
git log --oneline
# 出力: def5678 ログイン画面のUIバグ修正
#        xyz3456 mainブランチの最新コミット

複数のコミットを連続で移動する

連続した複数のコミットを一度に適用する場合は、範囲指定構文を使います。

# コミット B から コミット D までを連続適用(B自体は含まれない)
git cherry-pick B..D

# コミット B から コミット D までを連続適用(B自体も含める)
git cherry-pick B^..D

具体例です。

git log feature-branch --oneline
# 出力: aaa1111 機能3実装
#        bbb2222 機能2実装
#        ccc3333 機能1実装
#        ddd4444 既存コード

# 機能1〜3をまとめて main に適用(機能1は含まない)
git cherry-pick ddd4444..aaa1111

# 機能1〜3をまとめて main に適用(機能1も含める)
git cherry-pick ccc3333^..aaa1111

実務シーン別の活用パターン

パターン1: ホットフィックスを本番ブランチにだけ適用

開発ブランチで本来であれば本番環境に即座に適用すべき重要なバグ修正を発見した場合、 そのコミットだけを本番ブランチに先行適用できます。

# 現在は develop ブランチで作業中
git checkout develop

# 重要なセキュリティバグ修正を発見(コミットハッシュ: sec9999)
# まず本番ブランチに切り替える
git checkout production

# そのセキュリティ修正を production に適用
git cherry-pick sec9999

# productionをデプロイして、その後developに戻る
git checkout develop

# 後で develop にもマージ(重複を避けるためマージ --no-commit で確認)
git merge production --no-ff

パターン2: リリースブランチから複数のバグ修正を取り込む

リリース候補ブランチで見つかった複数のバグ修正を、 まだ開発中の次期版ブランチにも反映させたい場合です。

# release-1.2 ブランチでのバグ修正コミットを確認
git log release-1.2 --oneline -5
# 出力: bug1001 ページネーションバグ修正
#        bug1002 フォーム送信エラー修正
#        bug1003 キャッシュ問題修正

# develop ブランチに切り替える
git checkout develop

# 3つのバグ修正を連続適用
git cherry-pick bug1003..bug1001

# または個別に指定することも可能
git cherry-pick bug1001 bug1002 bug1003

よくあるトラブルとその対応策

コンフリクト発生時の処理

cherry-pick実行時に、対象ブランチのコード変更と競合する場合があります。

# cherry-pickでコンフリクト発生
git cherry-pick def5678
# 出力: error: could not apply def5678... ログイン画面のUIバグ修正
#       hint: after resolving the conflicts, mark the resolution with:
#       hint: git add/rm <pathspec>
#       hint: git cherry-pick --continue

# 1. コンフリクト部分をエディタで手動修正
# ファイルを開いて <<<<< HEAD と >>>>> の間を調整

# 2. 修正したファイルをステージング
git add conflicted_file.js

# 3. cherry-pick を継続
git cherry-pick --continue

# もし途中で中止したい場合
git cherry-pick --abort

コミットメッセージの確認

cherry-pickは元のコミットメッセージをそのまま保持します。 メッセージを編集したい場合は --editフラグを使用します。

# cherry-pick 時にメッセージを編集
git cherry-pick --edit def5678

# 短縮形
git cherry-pick -e def5678

cherry-pickを使うべき場面と避けるべき場面

✅ 使うべき場面

  • 緊急のセキュリティパッチを本番環境に先行適用する必要がある
  • リリースブランチでの修正を次期開発ブランチにも反映させたい
  • 機能ブランチの一部のコミットだけを別ブランチに取り込みたい
  • ホットフィックスを複数の保守ブランチに適用する

❌ 避けるべき場面

  • ブランチ全体の変更を統合する場合(git mergegit rebaseを使用)
  • コミット履歴の順序関係が重要な場合
  • チームで共有されたブランチ履歴を改変する場合
  • 複雑な依存関係のあるコミットを無視して個別に適用する場合

類似ツールとの使い分け

Gitには複数のコミット適用手段があります。以下が使い分けの目安です。

  • cherry-pick: 特定の個別コミットを別ブランチに適用。最も細粒度な制御
  • merge: ブランチ全体を統合。マージコミットで履歴を保持
  • rebase: ブランチの根拠となるコミットを変更。線形な履歴を保つが、既に公開されたブランチには使用厳禁

cherry-pickは最も細かい制御ができる一方、乱用するとコミット履歴が複雑になるため、 本当に必要な場面に限定して使用することをお勧めします。

よくある質問

はい、残ります。cherry-pickは「コピー」操作であり、元のブランチのコミットを移動するわけではありません。 元のブランチのコミットは変わらず存在します。もし元のコミットを削除したい場合は、別途リセット操作が必要です。

git cherry-pick --abortで全体をキャンセルするか、 git reset --hard HEADで状態をリセットしてやり直してください。 個別ファイルの選別適用は設計上サポートされていません。

はい可能ですが、古いコミットほどコンフリクトのリスクが高まります。 理由は、その後のコード変更が累積しているためです。 コンフリクト解決に自信がない場合は、事前に対象ブランチでテストすることをお勧めします。

まとめ

  • git cherry-pick <commit-hash>で特定コミットを現在のブランチに適用できる
  • 複数コミットの連続適用はcherry-pick B..Dの範囲指定構文で効率的に実行可能
  • コンフリクト発生時は手動修正後にgit cherry-pick --continueで再開できる
  • ホットフィックスやリリースブランチでの修正取り込みなど、実務では頻出のシーン
  • ブランチ全体の統合はmergerebaseを使用し、cherry-pickは本当に必要な場面に限定すること

cherry-pickは一見単純なコマンドですが、適切に使い分けることでGitワークフローを大幅に効率化できます。 Git公式ドキュメント(git cherry-pick) も参考にしながら、チームの運用ルールに応じて活用してください。

K
AWS・Python・生成AIを専門とするソフトウェアエンジニア。AI・クラウド・開発ワークフローの実践ガイドを執筆しています。詳しく見る →