如何在沒有合並的情況下從另一個分支獲取提交？

Question

從表面上看，這似乎是櫻桃采摘的教科書用例。 谷歌搜索，我發現如下語句：

Git 中的櫻桃采摘意味着從一個分支中選擇一個提交並將其應用於另一個分支。

命令 git cherry-pick commit 應用由當前分支上的命名提交引入的更改。

所以我 go 並嘗試一下......我的一半文件變成了合並沖突（常規合並將另外 8 個其他文件變成合並沖突，所以這也沒有用）。 有問題的提交只更改了大約 5 行左右，而不是文件的一半。

對於上下文，這 2 個分支大致如下所示：

1. P -> [20 次提交] -> A -> B = other_branch
2. P -> [30 個不相關的提交] -> C = my_branch

提交 B 所做的唯一事情是更改 foo.py 中的約 5 行我想將這些更改選擇為提交 C，但顯然櫻桃選擇討厭我。

我發現了這些其他相關問題：

git cherry-pick 有什么用例？

櫻桃挑選的問題：也應用了以前提交的更改

他們認為上面的報價實際上是謊言，而cherry pick實際上是一個花哨的3路合並？ 我認為其中一個（或另一個問題）提供了以下解決方案：

git show commitB > patch.txt
git apply patch.txt

我也試過

git diff commitA commitB | git apply

但我得到的只是

error: patch failed: foo.py:20
error: foo.py: patch does not apply

手動復制意大利面是我唯一的解決方案嗎？

在相關說明中，git 櫻桃挑選適合什么/什么時候適合？ 我想不出任何好的用例。 如果 2 個分支略有不同，則普通的舊合並幾乎可以完成相同的操作。 如果 2 個分支差異很大（我的情況），櫻桃采摘就會失敗。

Answer 1

Cherry-pick 不能簡單地“復制提交”。 Git 中的提交引用了一棵樹，而一棵樹是整個項目文件（以及隱含的目錄）的完整快照。

當您執行挑選時，Git 將首先計算“此提交的更改”（基本上運行git diff thatcommit thatcommit^ ），然后嘗試將這些更改重新應用到您當前的 HEAD。 通常，這工作得很好。 鑒於在選擇提交中更改的文件與您當前的 HEAD 提交沒有太大差異。 如果兩個分支中相同的行（或附近的行）發生了變化，Git 不能自動合並（或挑選）這些變化。 僅僅是因為它無法檢測到哪些是“正確”的變化。

因此，當您說文件僅更改了 5 行時，櫻桃選擇應該干凈地應用。 當然，除非有更多的行發生了變化，例如，行尾在一個分支中被規范化，但在另一個分支中沒有（命令行標志對此有所幫助）。

要快速找出您的文件在兩個分支上的差異程度，請運行 diff: git diff branchA branchB -- foo.py 。

如果更改了更多行（根據您的描述，聽起來是這樣），您最好手動重新應用這些更改。 但是，既然您聲稱只有幾行發生了變化，那應該不是那么困難。

Answer 2

為什么會發生沖突：

假設您處於以下情況：

--*--*--*--*--*--H <- HEAD, mybranch (your current state)
   \
    *--*--x--y--* <- some/otherbranch
             ^
       (the commit you want to cherry pick)

如果您運行git cherry-pick <y> ， git 將嘗試協調：

• 提交引入的更改，即：diff x -> y
• 在您的分支上進行更改： x -> H之間的差異

所以：如果補丁說“第 22 行有更改”，並且您的分支也在第 22 行引入了更改（與x相比），那么您肯定會遇到沖突。

（其實就算22行附近有變化，也會有沖突）

---

如何解決沖突：

解決沖突的一種足夠體面的方法是在 3 路差異查看器中編輯它們，例如kdiff3或winmerge或meld或...

您可以通過運行git mergetool讓git為您打開 3 路差異合並工具：

git mergetool
# if you want to select a specific mergetool:
git mergetool --tool=vimdiff

如果您選擇的提交只引入了一些更改，那么修復沖突將看起來很像：

• 主要從當前提交（“我們的”方面）獲取內容
• 包括提交y中引入的一些更改

最后：您可以選擇提交的內容作為“正確”版本，以包含來自提交y的更改。