?
This document uses PHP Chinese website manual Release
命名
git-cherry-pick - 應(yīng)用一些現(xiàn)有提交引入的更改
概要
git cherry-pick [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] [-S[<keyid>]] <commit>… git cherry-pick --continuegit cherry-pick --quit git cherry-pick --abort
描述
給定一個或多個現(xiàn)有的提交，應(yīng)用每個引入的更改，為每個提交一個新的提交。這要求你的工作樹是干凈的（不需要修改 HEAD 提交）。
如果不清楚如何應(yīng)用更改，則會發(fā)生以下情況：
當前分支和
HEAD指針停留在最后一次成功提交。該
CHERRY_PICK_HEADRef設(shè)定點在提交該介紹，很難應(yīng)用更改。干凈地應(yīng)用更改的路徑在索引文件和工作樹中都會更新。
對于沖突的路徑，索引文件最多可以記錄三個版本，如 git-merge [1] 的 “TRUE MERGE” 部分所述。工作樹中的文件將包括通常的沖突標記括號沖突的描述
<<<<<<<和>>>>>>>。沒有其他修改。
有關(guān)解決此類沖突的一些提示，請參閱 git-merge [1]。
選項
<commit>…
遞交 cherry-pick 。有關(guān)拼寫提交的更完整列表，請參閱 gitrevisions [7]?？梢詡鬟f提交集，但默認情況下不進行遍歷，就像--no-walk指定了選項一樣，請參閱 git-rev-list [1] 。請注意，指定一個范圍會將所有 <commit> ...參數(shù)提供給單個修訂步驟（請參閱稍后使用的示例maint master..next）。
-e --edit
使用此選項，git cherry-pick可讓您在提交之前編輯提交消息。
-x
當記錄提交時，在原始提交消息中附加一行說“（從挑選中提取的櫻桃...）”，以表明該更改是從哪個提交中挑選出來的。這只對櫻桃選擇沒有沖突。如果您正在從您的私人分支進行挑選，請勿使用此選項，因為這些信息對收件人無用。另一方面，如果您在兩個公開可見的分支之間進行選擇（例如，向開發(fā)分支中的舊版本的維護分支返回修復），添加此信息可能很有用。
-r
它曾經(jīng)是命令默認做-x了上面描述，并且-r是禁用它?，F(xiàn)在默認不這樣做-x，這個選項是沒有操作的。
-m parent-number --mainline parent-number
通常你不能選擇合并，因為你不知道合并的哪一邊應(yīng)該被認為是主線。此選項指定主線路的父代號碼（從1開始），并允許 cherry-pick 重播相對于指定的父代的更改。
-n --no-commit
通常，該命令會自動創(chuàng)建一系列提交。此標志應(yīng)用所需的更改，以便將每個命名提交挑選到工作樹和索引，而不進行任何提交。此外，使用此選項時，您的索引不必與 HEAD 提交匹配。cherry-pick 是根據(jù)索引的開始狀態(tài)完成的。
當在一行中選擇多個“索引”效果到索引時，這非常有用。
-s --signoff
在提交消息的末尾添加 Signed-off-by 行。有關(guān)更多信息，請參閱 git-commit [1] 中的 signoff 選項。
-S<keyid> --gpg-sign=<keyid>
GPG 標志提交。該keyid參數(shù)是可選的，并且默認為提交者身份; 如果指定，它必須粘貼到選項沒有空格。
--ff
如果當前的 HEAD 與 cherry-pick 的提交的父對象相同，則將執(zhí)行快速轉(zhuǎn)發(fā)此提交。
--allow-empty
默認情況下，cherry-pick 一個空的提交將失敗，表明需要顯式調(diào)用git commit --allow-empty。該選項會覆蓋該行為，允許空提交在 cherry-pick 中自動保留。請注意，當“--ff”有效時，即使沒有此選項，也會保留符合“快進”要求的空提交。還要注意，使用這個選項只保留最初為空的提交（即提交記錄與其父代相同的樹）。由于先前的提交而提交的提交被刪除。強制包含這些提交使用--keep-redundant-commits。
--allow-empty-message
默認情況下，用空信息挑選提交將失敗。該選項將覆蓋該行為，允許提交空消息提交。
--keep-redundant-commits
如果提交 cherry-pick 復制了當前歷史記錄中的提交，它將變?yōu)榭铡ＤJ情況下，這些冗余提交會導致cherry-pick停止，以便用戶可以檢查提交。該選項將覆蓋該行為并創(chuàng)建一個空的提交對象。意味著--allow-empty。
--strategy=<strategy>
使用給定的合并策略。只能使用一次。有關(guān)詳細信息，請參閱 git-merge [1] 中的 MERGE STRATEGIES 部分。
-X<option> --strategy-option=<option>
將合并策略特定選項傳遞給合并策略。有關(guān)詳細信息，請參閱 git-merge [1] 。
Sequencer 子命令
--continue
使用中的信息繼續(xù)正在進行的操作.git/sequencer。可以在解決失敗的 cherry-pick 或恢復中的沖突后繼續(xù)使用。
--quit
忘記當前正在進行的操作。在 cherry-pick 或恢復失敗后可用于清除定序器狀態(tài)。
--abort
取消操作并返回到預序列狀態(tài)。
例子
git cherry-pick master
在主分支的頂端應(yīng)用由提交引入的更改，并使用此更改創(chuàng)建新的提交。
git cherry-pick ..master git cherry-pick ^HEAD master
應(yīng)用所有提交的引用變更，這些提交是 master 的祖先，但不是 HEAD 的祖先，以產(chǎn)生新的提交。
git cherry-pick maint next ^master git cherry-pick maint master..next
應(yīng)用所有提交的所有提交的變更，這些提交是 maint 或 next 的祖先，但不是 master 或其祖先。需要注意的是，后者并不意味著maint之間的一切，master和next; 具體而言，maint如果包含在內(nèi)，則不會被使用master。
git cherry-pick master~4 master~2
應(yīng)用由 master 指向的第五次和第三次提交所引入的更改，并創(chuàng)建兩個新提交并進行這些更改。
git cherry-pick -n master~1 next
向工作樹和索引應(yīng)用由 master 指向的第二次提交引入的更改以及 next 指向的最后一個提交的更改，但不要使用這些更改創(chuàng)建任何提交。
git cherry-pick --ff ..next
如果歷史記錄是線性的并且 HEAD 是下一個祖先，則更新工作樹并前進 HEAD 指針以匹配下一個。否則，將那些位于 next 而不是 HEAD 的提交引入的更改應(yīng)用于當前分支，為每個新更改創(chuàng)建一個新的提交。
git rev-list --reverse master -- README | git cherry-pick -n --stdin
將觸及 README 的主分支上的所有提交引入的更改應(yīng)用于工作樹和索引，以便可以檢查結(jié)果并在合適的情況下將其作為單個新提交。
以下順序嘗試回溯修補程序，因為修補程序適用的代碼發(fā)生了太多變化，然后再次嘗試，因此這段時間會更注意匹配上下文行。
$ git cherry-pick topic^ (1)$ git diff (2)$ git reset --merge ORIG_HEAD (3)$ git cherry-pick -Xpatience topic^ (4)
應(yīng)用將顯示的更改
git show topic^。在這個例子中，這個補丁并沒有很好的應(yīng)用，所以關(guān)于沖突的信息被寫入索引和工作樹，并且沒有新的提交結(jié)果。總結(jié)要調(diào)和的變化
取消 cherry-pick 。換句話說，返回到 cherry-pick 前的狀態(tài)，保留您在工作樹中進行的任何本地修改。
嘗試應(yīng)用
topic^再次引入的更改，花費額外的時間避免基于錯誤匹配的上下文行的錯誤。