git - 我误解了 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

通过在提交 4 中挑选

如果我有那个权利，那为什么它不起作用？我遇到了冲突，然后当我查看冲突时，看起来好像 git 正试图从提交 2、3、4 中提取行。这是我的工作日志(跳到 HERE'S THE MEAT 看肉..):

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 的内容交织在一起。提交的补丁4 看起来像这样:

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

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

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

所以它给你带来了冲突:HEAD 中的版本(提交 1)此时没有任何内容，而提交 4 中的版本有这三行。由您决定这两行是否是最后一行的“一部分”，是否需要一起插入以使插入有意义，或者它们是否与最后一行分开并且可以删除。这与您在正常 merge 冲突中看到的完全相同。

如果您在补丁不相交的示例中尝试此操作 - 提交 2 和 3 对提交 4 中的任何内容进行几行更改，或者更好的是，在来自提交 4 的不同文件中进行更改 - 您将看到您期望的行为从 cherry-pick 。您完全正确地理解了目的；你只是有一个困惑的测试用例。