我是不是误解了git cherry-pick？

Question

在阅读git cherry-pick的手册页时，我的理解是它只需要一次提交所引入的更改，然后您就可以将这些更改应用到几乎任何地方。

因此，假设我有一个文件，我通过4次提交构建了一个文件，如下所示：

line from commit 1
line from commit 2
line from commit 3
line from commit 4

如果我随后在提交1处开始另一个分支，我应该能够到达

line from commit 1
line from commit 4

通过在commit 4中挑选樱桃

如果我有这个权利，为什么它不起作用？我得到了一个冲突，然后当我查看冲突时，看起来git似乎正在尝试从提交2,3,4中拉入行。这是我的工作日志(跳到这里是肉来看肉...)：

szbwood-mbp15:proj5 bwood$ git init
Initialized empty Git repository in /Users/bwood/work/gitplay/proj5/.git/
szbwood-mbp15:proj5 bwood$ vi file1
szbwood-mbp15:proj5 bwood$ git add file1
szbwood-mbp15:proj5 bwood$ git commit -a
[master (root-commit) 4cb9b97] ..
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 file1
szbwood-mbp15:proj5 bwood$ vi file1
szbwood-mbp15:proj5 bwood$ git commit -a
[master 809d87c] ..
 1 files changed, 1 insertions(+), 0 deletions(-)
szbwood-mbp15:proj5 bwood$ vi file1
szbwood-mbp15:proj5 bwood$ git commit -a
[master b534ac9] ..
 1 files changed, 1 insertions(+), 0 deletions(-)
szbwood-mbp15:proj5 bwood$ vi file1
szbwood-mbp15:proj5 bwood$ git commit -a
[master fabc779] ..
 1 files changed, 1 insertions(+), 0 deletions(-)
szbwood-mbp15:proj5 bwood$ git log
commit fabc7795fb660d55a7ad5636321b6180157954f7
Author: B
Date:   Sun Nov 7 21:58:07 2010 -0800

    ..

commit b534ac9d1f8139fc7ffa9479a3d0cb0fd08c9508
Author: B
Date:   Sun Nov 7 21:57:53 2010 -0800

    ..

commit 809d87c24b1c2d27354d6bfcb34d3a1981cb7ae5
Author: B
Date:   Sun Nov 7 21:57:35 2010 -0800

    ..

commit 4cb9b97c3cae9b9551fa039f87e2fff5624fbbe3
Author: B
Date:   Sun Nov 7 21:57:19 2010 -0800

    ..
szbwood-mbp15:proj5 bwood$ git checkout 4cb9b97c3cae9b9551fa039f87e2fff5624fbbe3
Note: checking out '4cb9b97c3cae9b9551fa039f87e2fff5624fbbe3'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at 4cb9b97... ..
szbwood-mbp15:proj5 bwood$ git checkout -b new_branch
Switched to a new branch 'new_branch'

这是肉

szbwood-mbp15:proj5 bwood$ more file1
line from commit 1
szbwood-mbp15:proj5 bwood$ git cherry-pick -x fabc7795fb660d55a7ad5636321b6180157954f7
Automatic cherry-pick failed.  After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>'
and commit the result with: 

        git commit -c fabc7795fb660d55a7ad5636321b6180157954f7

szbwood-mbp15:proj5 bwood$ more file1
line from commit 1
<<<<<<< HEAD
=======
line from commit 2
line from commit 3
line from commit 4
>>>>>>> fabc779... ..
szbwood-mbp15:proj5 bwood$ 

Answer 1

这里的问题不是git实际上试图插入提交2和3的内容，而是提交4的内容与提交2和3的内容交织在一起。

 line from commit 1
 line from commit 2
 line from commit 3
+line from commit 4

(除非考虑到这看起来像是一个测试用例，我猜下面可能没有任何行。)

因此，当git尝试将该补丁应用于commit 1中的文件内容时，它会说，嗯，我需要在commit 3的行后插入此行。好的，文件里的那行是在哪里？它向后工作并设法将其匹配起来，但它知道有问题-它必须添加不属于补丁的行才能应用补丁。这里的关键思想是，补丁是通过匹配它们的边缘来应用的-补丁不仅仅是说“添加到文件的末尾”，它还说“在这一行后面添加这个内容”。

因此，它会给您带来冲突: HEAD (commit 1)中的版本在这一点上没有任何内容，而commit 4中的版本具有这三行。您可以决定这两行是最后一行的“一部分”，是否需要带上以使插入有意义，或者它们是否与最后一行分开并可以删除。这与您在普通合并冲突中看到的情况完全相同。

如果你在一个补丁不相交的例子中尝试这样做-- commit 2和commit 3使更改与commit 4中的任何东西相隔几行，或者更好的是，在commit 4中的不同文件中--您将看到从cherry-pick中期望的行为。您完全正确地理解了目的；您只有一个凌乱的测试用例。