我误解了git cherry-pick?

时间:2010-11-08 06:05:16

标签: git

在阅读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中引入行。这是我工作的日志(跳到这里吃肉,看看肉......):

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$ 

1 个答案:

答案 0 :(得分:17)

这里的问题不是git实际上尝试从提交2和3插入内容,而是来自提交4的内容与来自提交2和3的内容交织在一起。提交的补丁4看起来像这样:

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

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

因此,当git尝试将该补丁应用于commit 1中的文件内容时,它说,嗯,我需要在提交3行之后插入这一行。哦,哦,那不是在这里。好的,文件中的那一行在哪里?它向后工作并设法匹配它,但知道一些可疑的东西 - 它必须添加不是补丁的一部分的行,以使补丁适用。这里的关键思想是通过匹配边缘来应用补丁 - 补丁不只是说“添加到文件的末尾”,它说“在此行之后添加此内容”。

所以它给你冲突:HEAD(提交1)中的版本在这个位置什么也没有,而提交4中的版本有这三行。由你来决定这两行是否是最后一行的“一部分”,并且需要带来插入才有意义,或者它们是否与它分开,并且可以被删除。这与正常的合并冲突完全相同。

如果你在一个修补程序不相交的例子上尝试这个 - 提交2和3在提交4中的任何内容做几行更改,或者更好,在提交4的不同文件中 - 你会看到你期望的行为来自cherry-pick。你完全正确地理解了目的;你只是有一个凌乱的测试用例。