cherry-pick

NAME名

git-cherry-pick - Apply the changes introduced by some existing commitsgit-cherry-pick - いくつかの既存のコミットによって導入された変更を適用する

SYNOPSIS概要

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

DESCRIPTION説明

Given one or more existing commits, apply the change each one introduces, recording a new commit for each. This requires your working tree to be clean (no modifications from the HEAD commit).1つ以上の既存のコミットがある場合は、それぞれが導入した変更を適用し、それぞれに新しいコミットを記録します。これはあなたの作業ツリーがきれいであることを必要とします（HEADコミットからの変更なし）。

When it is not obvious how to apply a change, the following happens:変更を適用する方法が明確でない場合は、次のようになります。

The current branch and HEAD pointer stay at the last commit successfully made.現在の分岐とHEADポインタは、最後に成功したコミットのままになります。
The CHERRY_PICK_HEAD ref is set to point at the commit that introduced the change that is difficult to apply.CHERRY_PICK_HEADrefは適用することは困難であるの変化を導入し、そのコミットを指すように設定されています。
Paths in which the change applied cleanly are updated both in the index file and in your working tree.変更が正しく適用されたパスは、インデックスファイルと作業ツリーの両方で更新されます。
For conflicting paths, the index file records up to three versions, as described in the "TRUE MERGE" section of git-merge[1]. The working tree files will include a description of the conflict bracketed by the usual conflict markers <<<<<<< and >>>>>>>.競合するパスの場合、git-merge [1]の "TRUE MERGE"セクションで説明されているように、インデックスファイルは最大3つのバージョンを記録します。作業ツリーのファイルは、通常の競合マーカーで囲ま紛争の記述が含まれます<<<<<<<とを>>>>>>>。
No other modifications are made.他の変更は行われません。

See git-merge[1] for some hints on resolving such conflicts.そのような衝突を解決するためのいくつかのヒントについてはgit-merge [1]を見てください。

OPTIONSオプション

<commit>… <コミット>…

Commits to cherry-pick. For a more complete list of ways to spell commits, see gitrevisions[7]. Sets of commits can be passed but no traversal is done by default, as if the --no-walk option was specified, see git-rev-list[1]. Note that specifying a range will feed all <commit>… arguments to a single revision walk (see a later example that uses maint master..next).チェリーピックを約束します。コミットを綴る方法のより完全なリストはgitrevisions [7]を参照してください。コミットのセットを渡すことはできますが、--no-walkオプションが指定されている場合と同様に、デフォルトでは走査は行われません。git-rev-list [1]を参照してください。範囲を指定すると、すべての<commit>…引数が単一のリビジョンウォークに送られることに注意してください（maint master..nextを使用する後の例を参照してください）。

-e

--edit - 編集

With this option, git cherry-pick will let you edit the commit message prior to committing.このオプションを指定すると、git cherry-pickはコミットする前にコミットメッセージを編集させます。

-x -バツ

When recording the commit, append a line that says "(cherry picked from commit …)" to the original commit message in order to indicate which commit this change was cherry-picked from. This is done only for cherry picks without conflicts. Do not use this option if you are cherry-picking from your private branch because the information is useless to the recipient. If on the other hand you are cherry-picking between two publicly visible branches (e.g. backporting a fix to a maintenance branch for an older release from a development branch), adding this information can be useful.コミットを記録するときは、この変更がどのコミットからチェリーピックされたのかを示すために、元のコミットメッセージに「（commit…from commit…）」という行を追加します。これは競合のないチェリーピックに対してのみ行われます。あなたのプライベートブランチからチェリーピッキングする場合は、このオプションを使用しないでください。情報が受信者には役に立たないためです。一方、2つの一般に公開されているブランチ（チェリーピッキングを開発ブランチからの古いリリース用のメンテナンスブランチへのバックポート）の間で選択している場合は、この情報を追加すると便利です。

-r

It used to be that the command defaulted to do -x described above, and -r was to disable it. Now the default is not to do -x so this option is a no-op.以前はコマンドがデフォルトで-x上記のように動作してい-rたため、無効にしていました。現在のデフォルトはそうではない-xので、このオプションは何もしません。

-m parent-number -m親番号

--mainline parent-number - メインラインの親番号

Usually you cannot cherry-pick a merge because you do not know which side of the merge should be considered the mainline. This option specifies the parent number (starting from 1) of the mainline and allows cherry-pick to replay the change relative to the specified parent.マージのどちら側をメインラインと見なすべきかわからないため、通常はマージを選択することはできません。このオプションはメインラインの（1から始まる）親番号を指定し、チェリーピックが指定された親に関連して変更を再生することを可能にします。

-n

--no-commit

Usually the command automatically creates a sequence of commits. This flag applies the changes necessary to cherry-pick each named commit to your working tree and the index, without making any commit. In addition, when this option is used, your index does not have to match the HEAD commit. The cherry-pick is done against the beginning state of your index.通常、このコマンドは自動的に一連のコミットを作成します。このフラグは、コミットを行わずに、作業ツリーとインデックスへの各名前付きコミットを選択するために必要な変更を適用します。さらに、このオプションを使用すると、インデックスはHEADコミットと一致する必要はありません。チェリーピックは、インデックスの最初の状態に対して行われます。

This is useful when cherry-picking more than one commits' effect to your index in a row.これは、チェリーピッキングで連続してあなたのインデックスに影響を与える場合に便利です。

-s

--signoff - サインオフ

Add Signed-off-by line at the end of the commit message. See the signoff option in git-commit[1] for more information.コミットメッセージの最後にサインオフラインを追加します。詳細についてはgit-commit [1]のsignoffオプションを参照してください。

-S[<keyid>] -S [<keyid>]

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

GPG-sign commits. The keyid argument is optional and defaults to the committer identity; if specified, it must be stuck to the option without a space.GPG-signがコミットします。keyid引数はコミッターのアイデンティティオプションで、デフォルトです。指定した場合は、スペースなしでオプションに固定する必要があります。

--ff

If the current HEAD is the same as the parent of the cherry-pick’ed commit, then a fast forward to this commit will be performed.現在のHEADがチェリー選択コミットの親と同じである場合は、このコミットへの早送りが行われます。

--allow-empty - 許可 - 空

By default, cherry-picking an empty commit will fail, indicating that an explicit invocation of git commit --allow-empty is required. This option overrides that behavior, allowing empty commits to be preserved automatically in a cherry-pick. Note that when "--ff" is in effect, empty commits that meet the "fast-forward" requirement will be kept even without this option. Note also, that use of this option only keeps commits that were initially empty (i.e. the commit recorded the same tree as its parent). Commits which are made empty due to a previous commit are dropped. To force the inclusion of those commits use --keep-redundant-commits.デフォルトでは、空のコミットを選択することは失敗しますgit commit --allow-empty。これは明示的なの呼び出しが必要であることを示します。このオプションはその振る舞いを無効にし、空のコミットがチェリーピックで自動的に保存されるようにします。"--ff"が有効な場合、 "早送り"の要件を満たす空のコミットは、このオプションがなくても保持されます。また、このオプションを使用しても、最初は空だったコミットだけが保持されます（つまり、コミットはその親と同じツリーを記録しました）。前のコミットのために空にされたコミットはドロップされます。それらのコミットを含めることを強制するにはを使用します--keep-redundant-commits。

--allow-empty-message

By default, cherry-picking a commit with an empty message will fail. This option overrides that behavior, allowing commits with empty messages to be cherry picked.デフォルトでは、空のメッセージでコミットを選択すると失敗します。このオプションはその振る舞いを無効にし、空のメッセージを含むコミットを選択することを可能にします。

--keep-redundant-commits --keep-redundant-commit

If a commit being cherry picked duplicates a commit already in the current history, it will become empty. By default these redundant commits cause cherry-pick to stop so the user can examine the commit. This option overrides that behavior and creates an empty commit object. Implies --allow-empty.選択されているコミットが現在の履歴内のコミットと重複している場合、それは空になります。デフォルトでは、これらの冗長なコミットcherry-pickは停止し、ユーザーはコミットを確認できます。このオプションはその動作を無効にして、空のコミットオブジェクトを作成します。ほのめかし--allow-emptyます。

--strategy=<strategy> --strategy = <strategy>

Use the given merge strategy. Should only be used once. See the MERGE STRATEGIES section in git-merge[1] for details.与えられたマージ戦略を使います。一度だけ使用されるべきです。詳細はgit-merge [1]のMERGE STRATEGIESセクションを参照してください。

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

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

Pass the merge strategy-specific option through to the merge strategy. See git-merge[1] for details.マージストラテジ固有のオプションをマージストラテジに渡します。詳細はgit-merge [1]を見てください。

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

--continue - 持続する: Continue the operation in progress using the information in .git/sequencer. Can be used to continue after resolving conflicts in a failed cherry-pick or revert..git / sequencerの情報を使用して進行中の操作を続行してください。失敗したチェリーピックまたは元に戻すことで競合を解決した後に続行するために使用できます。
--quit - 終了する: Forget about the current operation in progress. Can be used to clear the sequencer state after a failed cherry-pick or revert.進行中の現在の操作を忘れます。チェリーピックまたは復帰に失敗した後にシーケンサーの状態をクリアするために使用できます。
--abort - アボート: Cancel the operation and return to the pre-sequence state.操作をキャンセルしてシーケンス前の状態に戻ります。

EXAMPLES例

git cherry-pick master: Apply the change introduced by the commit at the tip of the master branch and create a new commit with this change.マスターブランチの先端でコミットによって導入された変更を適用し、この変更で新しいコミットを作成します。
git cherry-pick ..master
git cherry-pick ^HEAD master: Apply the changes introduced by all commits that are ancestors of master but not of HEAD to produce new commits.新しいコミットを生成するために、masterではなくHEADの祖先であるすべてのコミットによって導入された変更を適用します。
git cherry-pick maint next ^master
git cherry-pick maint master..next: Apply the changes introduced by all commits that are ancestors of maint or next, but not master or any of its ancestors. Note that the latter does not mean maint and everything between master and next; specifically, maint will not be used if it is included in master.maintまたはnextの先祖であるが、masterまたはその先祖のいずれでもない、すべてのコミットによって導入された変更を適用します。後者はmaintとの間のすべてを意味するものではmasterありませんnext。特にmaint含まれている場合は使用されませんmaster。
git cherry-pick master~4 master~2: Apply the changes introduced by the fifth and third last commits pointed to by master and create 2 new commits with these changes.masterが指している5番目と3番目の最後のコミットによって導入された変更を適用し、これらの変更で2つの新しいコミットを作成します。
git cherry-pick -n master~1 next: Apply to the working tree and the index the changes introduced by the second last commit pointed to by master and by the last commit pointed to by next, but do not create any commit with these changes.masterが指す2番目の最後のコミットとnextが指す最後のコミットによって導入された変更を作業ツリーとインデックスに適用します。ただし、これらの変更でコミットを作成しないでください。
git cherry-pick --ff ..next: If history is linear and HEAD is an ancestor of next, update the working tree and advance the HEAD pointer to match next. Otherwise, apply the changes introduced by those commits that are in next but not HEAD to the current branch, creating a new commit for each new change.履歴が線形で、HEADがnextの先祖である場合は、作業ツリーを更新し、HEADポインタをnextに一致するように進めます。そうでなければ、HEADではなくnextにあるコミットによって導入された変更を現在のブランチに適用し、新しい変更ごとに新しいコミットを作成します。
git rev-list --reverse master -- README | git cherry-pick -n --stdin: Apply the changes introduced by all commits on the master branch that touched README to the working tree and index, so the result can be inspected and made into a single new commit if suitable.READMEに触れたマスターブランチ上のすべてのコミットによって導入された変更を作業ツリーとインデックスに適用します。そうすれば、結果は検査され、適切であれば単一の新しいコミットになります。

The following sequence attempts to backport a patch, bails out because the code the patch applies to has changed too much, and then tries again, this time exercising more care about matching up context lines.次のシーケンスはパッチをバックポートしようとしますが、パッチが適用されるコードがあまりにも変更されたために失敗した後、もう一度試します。今度はコンテキスト行のマッチングについてもっと注意を払います。

$ git cherry-pick topic^             (1)
$ git diff                           (2)
$ git reset --merge ORIG_HEAD        (3)
$ git cherry-pick -Xpatience topic^  (4)

apply the change that would be shown by git show topic^. In this example, the patch does not apply cleanly, so information about the conflict is written to the index and working tree and no new commit results.で示される変更を適用してくださいgit show topic^。この例では、パッチはきれいには適用されないため、競合に関する情報はインデックスと作業ツリーに書き込まれ、新しいコミット結果は得られません。
summarize changes to be reconciled調整する変更を要約する
cancel the cherry-pick. In other words, return to the pre-cherry-pick state, preserving any local modifications you had in the working tree.チェリーピックをキャンセルします。言い換えれば、作業ツリーで行ったローカルの変更を保持しながら、チェリーピック前の状態に戻ります。
try to apply the change introduced by topic^ again, spending extra time to avoid mistakes based on incorrectly matching context lines.topic^誤って一致したコンテキスト行に基づいてミスを回避するために余分な時間を費やして、再度導入した変更を適用してみてください。