SYNOPSIS

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

DESCRIPTION

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

変更を適用する方法が明確でない場合、以下のようになります:

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

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

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

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

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

このような競合を解決するための幾つかのヒントについては、 git-merge(1) を参照してください。

OPTIONS

<commit>…

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

-e
--edit

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

--cleanup=<mode>

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

-x

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

-r

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

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

マージのどちら側をメインラインと見なすべきかわからないため、通常、マージを選択することはできません。 このオプションは、メインラインの親番号(1から始まる)を指定し、cherry-pickが指定された親に関連する変更を再実行(replay)できるようにします。

-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が、チェリーピックされたコミットの親と同じである場合、このコミットへの早送り(fast forward)が実行されます。

--allow-empty

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

--allow-empty-message

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

--keep-redundant-commits

チェリーピックされているコミットが現在の履歴にすでにあるコミットと重複している場合、そのコミットは空になります。 デフォルトでは、これらの冗長なコミットにより cherry-pick が停止するため、ユーザーはコミットを調べることができます。 このオプションはその動作をオーバーライドし、空のコミットオブジェクトを作成します。 --allow-empty の指定含んでいます。

--strategy=<strategy>

指定のマージ戦略を使用します。複数回指定できません。 詳細については、 git-merge(1) の「MERGE STRATEGIES」セクションを参照してください。

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

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

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

rerere メカニズムが現在の競合で記録された解決を再利用して作業ツリー内のファイルを更新した後、解決の結果でインデックスも更新できるようにします。 --no-rerere-autoupdate は、別の git add で結果をインデックスにコミットする前に、「rerere」が行ったことを再確認し、潜在的な間違いマージ(mismerges)を捉える良い方法です。

SEQUENCER SUBCOMMANDS

--continue

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

--skip

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

--quit

進行中の今回の操作を忘れてください。チェリーピックまたはrevertに失敗した後、シーケンサーの状態をクリアするために使用できます。

--abort

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

EXAMPLES

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 の間のすべてを意味するものではないことに注意してください。 具体的には、 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に一致するように進めます。 それ以外の場合は、次のコミットで導入された変更を現在のブランチに適用し、新しい変更ごとに新しいコミットを作成します。

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

READMEにアクセスしたmasterブランチのすべてのコミットによって導入された変更を作業ツリーとインデックスに適用します。これにより、結果を検査して、必要に応じて1つの新しいコミットにすることができます。

以下のシーケンスは、パッチのバックポートを試み、パッチが適用されるコードが大幅に変更されたためにベイルアウト(脱出; git reste)してから、再試行します。今度は、コンテキスト行の一致にさらに注意を払います。

$ 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. チェリーピックをキャンセルします。 つまり、作業ツリーで行ったローカルの変更を保持したまま、チェリーピック前の状態に戻ります。

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

SEE ALSO

git-revert(1)

GIT

Part of the git(1) suite