Git
英文 ▾ 主題 ▾ 最新版本 ▾ 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)

描述

給定一個或多個現有提交，套用每個提交所引入的變更，並為每個提交記錄一個新的提交。這需要您的工作目錄是乾淨的（沒有從 HEAD 提交的修改）。

當不清楚如何套用變更時，會發生以下情況

  1. 目前分支和 HEAD 指標會停留在最後一次成功建立的提交。

  2. CHERRY_PICK_HEAD 參考會設定為指向引入難以套用之變更的提交。

  3. 變更已順利套用的路徑會在索引檔和您的工作目錄中更新。

  4. 對於衝突路徑，索引檔會記錄最多三個版本，如 git-merge[1] 的「TRUE MERGE」章節中所述。工作目錄檔案將包含以常見的衝突標記 <<<<<<< 和 >>>>>>> 括起來的衝突描述。

  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 之前，會將剪刀附加到 MERGE_MSG。

-x

在記錄提交時，將一行文字「(cherry picked from commit …​)」附加到原始提交訊息，以指出此變更是從哪個提交揀選的。這僅針對沒有衝突的揀選執行。如果您是從私人分支揀選，請勿使用此選項，因為該資訊對接收者沒有用。另一方面，如果您是在兩個公開可見的分支之間揀選（例如，將修復程式從開發分支回溯移植到舊版本的維護分支），則新增此資訊可能會很有用。

-r

過去，該命令預設執行上述的 -x，而 -r 則是用於停用它。現在預設不會執行 -x，因此此選項是一個無作業。

-m <父系編號>
--mainline <父系編號>

通常您無法揀選合併，因為您不知道應該將合併的哪一方視為主要分支。此選項指定主要分支的父系編號（從 1 開始），並允許揀選重播相對於指定父系的變更。

-n
--no-commit

通常，該命令會自動建立一系列提交。此旗標會套用將每個已命名提交揀選至您的工作目錄和索引所需的變更，而不會進行任何提交。此外，當使用此選項時，您的索引不必與 HEAD 提交相符。揀選是針對您索引的開始狀態完成的。

當您依序將多個提交的效果揀選到您的索引時，這很有用。

-s
--signoff

在提交訊息結尾新增 Signed-off-by 尾部。有關更多資訊，請參閱 git-commit[1] 中的 signoff 選項。

-S[<keyid>]
--gpg-sign[=<keyid>]
--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 僅指定如何處理原本不是空的提交，而是因為之前的提交而變成空的狀況。最初就為空的提交仍然會導致 cherry-pick 失敗，除非指定 --empty=keep 或 --allow-empty 其中之一。

--keep-redundant-commits

已棄用的 --empty=keep 同義詞。

--strategy=<策略>

使用指定的合併策略。應該只使用一次。請參閱 git-merge[1] 中的「合併策略」章節以瞭解詳細資訊。

-X<選項>
--strategy-option=<選項>

將特定於合併策略的選項傳遞給合併策略。請參閱 git-merge[1] 以瞭解詳細資訊。

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

在 rerere 機制重複使用先前記錄的衝突解決方案來更新工作目錄中的檔案後，允許它也使用解決方案的結果更新索引。--no-rerere-autoupdate 是一個很好的方法，可以仔細檢查 rerere 的操作並捕獲潛在的合併錯誤，然後再使用單獨的 git add 將結果提交到索引。

SEQUENCER 子命令

--continue

使用 .git/sequencer 中的資訊繼續進行中的操作。可以用於在解決失敗的 cherry-pick 或 revert 中的衝突後繼續。

--skip

跳過當前提交並繼續處理其餘的序列。

--quit

忘記當前正在進行的操作。可以用於在失敗的 cherry-pick 或 revert 後清除 sequencer 狀態。

--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 中，則不會使用 maint。

git cherry-pick master~4 master~2

套用 master 所指向的倒數第五個和倒數第三個提交所引入的變更，並使用這些變更建立 2 個新的提交。

git cherry-pick -n master~1 next

將 master 所指向的倒數第二個提交和 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. 取消 cherry-pick。換句話說，返回到 cherry-pick 前的狀態，保留您在工作目錄中的任何本地修改。

  4. 嘗試再次套用 topic^ 引入的變更，花費額外的時間來避免因錯誤匹配上下文行而造成錯誤。

參見

git-revert[1]

GIT

屬於 git[1] 套件的一部分

scroll-to-top