日本語 ▾ トピック ▾ 最新バージョン ▾ git-cherry-pick は 2.50.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)

説明

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

変更の適用方法が明らかでない場合、以下のことが起こります。

  1. 現在のブランチと HEAD ポインタは、最後に成功したコミットに留まります。

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

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

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

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

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

オプション

<commit>…​

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

-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から始まる）を指定し、チェリーピックが指定された親に対して変更をリプレイすることを可能にします。

-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" が有効な場合、このオプションがなくても「ファストフォワード」要件を満たす空のコミットは保持されることに注意してください。また、このオプションを使用しても、最初に空だったコミット（つまり、コミットがその親と同じツリーを記録した場合）のみが保持されることに注意してください。前のコミットによって空になったコミットは、チェリーピックを失敗させます。これらのコミットの強制的な含めるには、--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>

指定されたマージ戦略を使用します。一度だけ使用する必要があります。詳細については、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 が何をしたかを確認し、潜在的なマージミスを検出するための良い方法です。

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

--continue

.git/sequencer の情報を使用して、進行中の操作を続行します。失敗したチェリーピックまたはリバートで競合を解決した後に続行するために使用できます。

--skip

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

--quit

進行中の現在の操作を忘れます。失敗したチェリーピックまたはリバートの後にシーケンサーの状態をクリアするために使用できます。

--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 に含まれている場合は使用されません。

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. チェリーピックをキャンセルします。言い換えれば、作業ツリーに残っていたローカルな変更を保持しながら、チェリーピック前の状態に戻ります。

  4. topic^ によって導入された変更を再度適用しようとします。不正確なコンテキスト行の一致による間違いを避けるためにより多くの時間を費やします。

関連項目

git-revert[1]

GIT

git[1]スイートの一部

scroll-to-top