English ▾ トピック ▾ 最新バージョン ▾ 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)

説明

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

変更の適用方法が不明確な場合、以下のことが起こります

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

  2. `CHERRY_PICK_HEAD` リファレンスは、適用が難しい変更を導入したコミットを指すように設定されます。

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

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

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

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

オプション

<コミット>…​

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

-e
--edit

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

--cleanup=<モード>

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

-x

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

-r

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

-m <親番号>
--mainline <親番号>

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

-n
--no-commit

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

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

-s
--signoff

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

-S[<キーID>]
--gpg-sign[=<キーID>]
--no-gpg-sign

GPG署名コミット。`keyid` 引数はオプションであり、デフォルトはコミッターの識別情報です。指定する場合は、スペースなしでオプションに付加する必要があります。`--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=<ストラテジー>

指定されたマージストラテジーを使用します。一度だけ使用すべきです。詳細については、git-merge[1] の MERGE STRATEGIES セクションを参照してください。

-X<オプション>
--strategy-option=<オプション>

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

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

rerereメカニズムが、現在の競合に対して記録された解決策を再利用してワーキングツリー内のファイルを更新した後、その解決結果でインデックスも更新することを許可します。`--no-rerere-autoupdate` は、`rerere` が何をしたかを再確認し、別の `git add` で結果をインデックスにコミットする前に潜在的なマージミスを捕捉する良い方法です。

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

--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`

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

以下のシーケンスはパッチをバックポートしようとしますが、パッチが適用されるコードが大きく変更されているため中断し、その後、今度はコンテキスト行の一致にさらに注意を払って再度試みます。

$ 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