最初，我認為 git cherry-pick 對其父級做了一個差異，生成一個補丁檔案，然后將該補丁應用到你的 HEAD 上，我認為這更有趣和獨特，而且我還沒有在 git 命令中看到這樣做然而。如果您有簡單的修復，例如您希望兩個分支產生相同的日志輸出，但您只在一個分支上修復它，并且您希望cherry-pick更改一行并將其應用到另一個分支，那么這樣的命令可能會很有用，這樣您現在就可以比較結果。但是，如果它只是將整個物件帶到您的 HEAD 上，那么我看不到這一點。
所以我的問題是，我將cherry-pick用于什么用例？因為它似乎僅用于提交歷史記錄管理（即，未將精選提交的所有父提交合并到當前 HEAD 中）。
uj5u.com熱心網友回復：
你對你的想法 git cherry-pick所做的描述與它實際所做的足夠接近，可以作為最初的描述。（因此，您提出的用例是主要用例。）要使其完全準確，我們需要做的是：
- 請注意，Git 的內部實作使用了 Git 的合并引擎，因此您有時會看到“合并沖突”。在這種情況下，cherry-pick 操作在中間停止，需要您解決沖突并使用
--continue它來完成它。 - 請注意，您可以一次選擇多個提交：在這種情況下，Git 一次執行每個選定的提交，如注釋 1 所示，然后繼續進行下一次提交。
- 請注意，使用 without
-n，每個挑選步驟 (a) 都要求作業樹和索引在開始時是“干凈的”（或多或少與當前提交匹配），并且每個被復制的提交都將其提交訊息復制為好吧，進入一個新的提交，再次導致這種干凈的狀態；但是使用-n，初始設定不需要“完全干凈”并且操作不會自己進行新的提交。1 - 請注意，這一切都使用了——至少可能是——sequencer（執行多次提交），就像 do
git revert和 modern 一樣git rebase，sequencer 一次只能做一件事，所以如果你正處于恢復或變基的中間，一些用例是有限的。
作為注釋的旁注，Git 中的術語object指的是 Git 的內部物件存盤。有四種物件型別：blob、樹、提交和帶注釋的標簽。一個blob物件存盤任何唯一的檔案內容（而不是檔案的名稱，也沒有它的 X VS -xchmod狀態），這是何等的Git去重復的檔案，檔案的內容，甚至內，之間共享任何給定的提交。一個樹物件存盤檔案名和模式資訊，一個提交物件存盤提交元資料（包括保存快照的樹物件的哈希 ID），一個標記物件存盤注釋的標記資料以供使用git tag -a和公司。如果我們忽略帶注釋標簽的特殊情況，提交只需要剩下的三個物件：一個用于存盤提交本身，一個或多個用于存盤樹資料，零個或多個用于存盤作為提交快照存盤的檔案內容.
Cherry-picking 將提交視為一個整體，并比較父項P與子項C以查看給定的提交對中發生了什么變化。為了將這些更改應用于當前(HEAD) 提交，它也會比較Pvs HEAD，這就是它最終使用合并引擎的原因和方式。（對于-n風格櫻桃選擇，它使用當前索引而不是HEAD提交。由于非-n櫻桃選擇需要它HEAD和索引匹配，它實際上可以總是使用索引。）
1 clean沒有正確、嚴格的定義，實際的實作往往是臨時的：任何需要“干凈狀態”的命令都會進行自己的檢查，從而確定對于該特定命令來說“干凈”意味著什么”。但是，在 中有一個require_clean_work_tree函式git-sh-setup，這為正確定義提供了一個很好的起點。請注意這里的子模塊是如何被忽略的，這可能并不總是合適的。
uj5u.com熱心網友回復：
能夠將提交從一個分支“復制”到另一個分支實際上非常有用，而無需進行合并，也無需手動重做所有編輯。
例如，在您的用例中，想象它不是單行日志輸出，而是您在開發分支上所做的重要錯誤修復。現在您希望將此修復程式向后移植到您的發布分支，用于補丁發布，但您顯然不想將開發分支合并到發布分支，因為自發布以來已經在那里提交了很多東西。你做什么作業？你git cherry-pick。
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/336980.html