Git
英語 ▾ トピック ▾ 最新バージョン ▾ git-cherry-pick は 2.45.0 で最終更新されました

名前

git-cherry-pick - 既存のコミットによって導入された変更を適用する

概要

git cherry-pick [--edit] [-n] [-m <parent-number>] [-s] [-x] [--ff]
		  [-S[<keyid>]] <commit>…​
git cherry-pick (--continue | --skip | --abort | --quit)

説明

一つ以上の既存のコミットが与えられた場合、それぞれが導入する変更を適用し、それぞれについて新しいコミットを記録します。 これには、作業ツリーがクリーンである必要があります（HEADコミットからの変更がないこと）。

変更の適用方法が明らかでない場合は、以下のようになります。

  1. 現在のブランチと HEAD ポインタは、最後に正常に作成されたコミットにとどまります。

  2. CHERRY_PICK_HEAD 参照は、適用が困難な変更を導入したコミットを指すように設定されます。

  3. 変更が正常に適用されたパスは、インデックスファイルと作業ツリーの両方で更新されます。

  4. 競合するパスについては、git-merge[1] の「真のマージ」セクションで説明されているように、インデックスファイルは最大3つのバージョンを記録します。 作業ツリーファイルには、通常の競合マーカー <<<<<<< と >>>>>>> で囲まれた競合の説明が含まれます。

  5. その他の変更は行われません。

このような競合の解決に関するヒントについては、git-merge[1] を参照してください。

オプション

<commit>…​

チェリーピックするコミット。コミットを指定する方法のより完全なリストについては、gitrevisions[7] を参照してください。コミットのセットを渡すことができますが、git-rev-list[1] で説明されているように、--no-walk オプションが指定されているかのように、デフォルトではトラバーサルは行われません。範囲を指定すると、すべての <commit>…​ 引数が単一のリビジョンウォークに渡されることに注意してください（後で *maint master..next* を使用する例を参照）。

-e
--edit

このオプションを指定すると、 *git cherry-pick* はコミットする前にコミットメッセージを編集できます。

--cleanup=<mode>

このオプションは、コミットメッセージがコミット機構に渡される前にどのようにクリーンアップされるかを決定します。 詳細については、git-commit[1] を参照してください。 特に、 *<mode>* に scissors の値が指定されている場合、競合が発生した場合に MERGE_MSG に渡される前に scissors が追加されます。

-x

コミットを記録する際に、変更がどのコミットからチェリーピックされたかを示すために、元のコミットメッセージに「(cherry picked from commit …​)」という行を追加します。これは、競合のないチェリーピックの場合にのみ行われます。受信者にとって情報が役に立たないため、プライベートブランチからチェリーピックする場合は、このオプションを使用しないでください。一方、2つの公開されているブランチ間でチェリーピックする場合（たとえば、開発ブランチから古いリリースのメンテナンスブランチに修正をバックポートする場合）、この情報を追加すると便利です。

-r

以前は、コマンドはデフォルトで上記で説明した `-x` を実行し、 `-r` はそれを無効にするためのものでした。現在はデフォルトで `-x` を実行しないため、このオプションは何もしません。

-m <parent-number>
--mainline <parent-number>

通常、マージのどちら側をメインラインと見なすかわからないため、マージをチェリーピックすることはできません。 このオプションは、メインラインの親番号（1から始まる）を指定し、チェリーピックが指定された親を基準に変更を再生できるようにします。

-n
--no-commit

通常、コマンドは自動的に一連のコミットを作成します。 このフラグは、コミットを行わずに、指定された各コミットをワーキングツリーとインデックスにチェリーピックするために必要な変更を適用します。 また、このオプションを使用する場合、インデックスはHEADコミットと一致する必要はありません。 チェリーピックは、インデックスの開始状態に対して行われます。

これは、複数のコミットの効果をインデックスに連続してチェリーピックする場合に便利です。

-s
--signoff

コミットメッセージの最後に `Signed-off-by` トレーラーを追加します。 詳細については、git-commit[1] のsignoffオプションを参照してください。

-S[<keyid>]
--gpg-sign[=<keyid>]
--no-gpg-sign

コミットにGPG署名します。 `keyid` 引数はオプションで、デフォルトはコミッターのIDです。指定する場合は、スペースなしでオプションに付ける必要があります。 `--no-gpg-sign` は、 `commit.gpgSign` 設定変数と以前の `--gpg-sign` の両方を無効にするのに役立ちます。

--ff

現在のHEADがチェリーピックされたコミットの親と同じである場合、このコミットへの早送りを実行します。

--allow-empty

デフォルトでは、空のコミットのチェリーピックは失敗し、`git commit --allow-empty` を明示的に呼び出す必要があることを示します。 このオプションは、その動作をオーバーライドし、空のコミットがチェリーピックで自動的に保持されるようにします。 "--ff" が有効になっている場合、"fast-forward" の要件を満たす空のコミットはこのオプションがなくても保持されることに注意してください。 また、このオプションを使用しても、最初に空だったコミット（つまり、コミットが親と同じツリーを記録したコミット）のみが保持されることに注意してください。以前のコミットのために空になったコミットは、チェリーピックの失敗を引き起こします。 これらのコミットを強制的に含めるには、`--empty=keep` を使用します。

--allow-empty-message

デフォルトでは、空のメッセージを持つコミットのチェリーピックは失敗します。 このオプションは、その動作をオーバーライドし、空のメッセージを持つコミットをチェリーピックできるようにします。

--empty=(drop|keep|stop)

現在の履歴に既に存在する変更と冗長なコミットがチェリーピックされる方法を処理します.

drop

コミットは削除されます。

keep

コミットは保持されます。 `--allow-empty` を意味します。

stop

コミットが適用されるとチェリーピックが停止し、コミットを調べることができます。 これがデフォルトの動作です。

`--empty=drop` と `--empty=stop` は、最初に空ではなかったが、以前のコミットのために空になったコミットの処理方法のみを指定することに注意してください。 最初に空だったコミットは、 `--empty=keep` または `--allow-empty` のいずれかが指定されていない限り、チェリーピックの失敗を引き起こします.

--keep-redundant-commits

--empty=keep の非推奨の同義語。

--strategy=<strategy>

指定されたマージ戦略を使用します。 1回だけ使用する必要があります。 詳細については、git-merge[1] のマージ戦略セクションを参照してください。

-X<option>
--strategy-option=<option>

マージ戦略固有のオプションをマージ戦略に渡します。 詳細については、git-merge[1] を参照してください。

--rerere-autoupdate
--no-rerere-autoupdate

rerere メカニズムが記録された解決策を現在の競合に再利用して作業ツリー内のファイルを更新した後、解決結果でインデックスも更新できるようにします。 --no-rerere-autoupdate は、rerere の動作をダブルチェックし、潜在的な誤マージを検出するための良い方法です。その後、別の git add で結果をインデックスにコミットします。

シーケンサーサブコマンド

--continue

.git/sequencer の情報を使用して、進行中の操作を続行します。失敗した cherry-pick または revert の競合を解決した後に続行するために使用できます。

--skip

現在のコミットをスキップして、シーケンスの残りの部分を続行します。

--quit

進行中の現在の操作を中止します。失敗した cherry-pick または revert の後にシーケンサーの状態をクリアするために使用できます。

--abort

操作をキャンセルし、シーケンス前の状態に戻します。

例

git cherry-pick master

master ブランチの先端にあるコミットによって導入された変更を適用し、この変更を含む新しいコミットを作成します。

git cherry-pick ..master
git cherry-pick ^HEAD master

master の祖先であるが HEAD の祖先ではないすべてのコミットによって導入された変更を適用して、新しいコミットを生成します。

git cherry-pick maint next ^master
git cherry-pick maint master..next

maint または next の祖先であるが、master またはその祖先ではないすべてのコミットによって導入された変更を適用します。後者は maint と master と next の間のすべてを意味するものではないことに注意してください。具体的には、maint が master に含まれている場合、maint は使用されません。

git cherry-pick master~4 master~2

master が指す 5 番目と 3 番目の最後のコミットによって導入された変更を適用し、これらの変更を含む 2 つの新しいコミットを作成します。

git cherry-pick -n master~1 next

master が指す最後から 2 番目のコミットと next が指す最後のコミットによって導入された変更を作業ツリーとインデックスに適用しますが、これらの変更を含むコミットは作成しません。

git cherry-pick --ff ..next

履歴が線形で HEAD が next の祖先である場合、作業ツリーを更新し、HEAD ポインターを next に一致するように進めます。そうでない場合、next にはあるが HEAD にはないコミットによって導入された変更を現在のブランチに適用し、新しい変更ごとに新しいコミットを作成します。

git rev-list --reverse master -- README | git cherry-pick -n --stdin

README に触れた master ブランチ上のすべてのコミットによって導入された変更を作業ツリーとインデックスに適用します。これにより、結果を検査し、適切な場合は単一の新しいコミットにすることができます。

次のシーケンスは、パッチのバックポートを試みますが、パッチが適用されるコードが変更されすぎて失敗し、次にコンテキスト行のマッチングに注意を払いながら再試行します。

$ git cherry-pick topic^             (1)
$ git diff                           (2)
$ git cherry-pick --abort            (3)
$ git cherry-pick -Xpatience topic^  (4)

  1. git show topic^ で表示される変更を適用します。この例では、パッチはクリーンに適用されないため、競合に関する情報はインデックスと作業ツリーに書き込まれ、新しいコミットは作成されません。

  2. 調整する変更を要約します。

  3. cherry-pick をキャンセルします。つまり、cherry-pick 前の状態に戻り、作業ツリーにあったローカルの変更を保持します。

  4. topic^ によって導入された変更を再度適用しようとします。コンテキスト行の誤った一致に基づくミスを避けるために、追加の時間を費やします。

関連項目

git-revert[1]

GIT

git[1] スイートの一部

scroll-to-top