git cherry pick是这个意思吗？

比方说

commit A^={toBeRemoved.txt, toBeModified.txt,old.txt} 
commit A={file1.txt(new added),added.txt(new added),toBeModified.txt(modified since A^),old.txt}
commit originally pointed by Branch B={file1.txt,toBeModified.txt,old.txt} 

然后

将在分支B的顶端生成一个新的提交a'，以便

A'={file1.txt(diff and merged,conflict possible),toBeModified.txt(diff and merged,conflict possible),added.txt,old.txt(from branch B)}

我不确定手册中“应用提交引入的更改”的含义。我认为A对A^所做的更改只涉及+added.txt和-toBeRemoved.txt。至于文件toBeModified.txt，无论它是否真的从^开始被修改，它总是可能导致冲突，就像file1.txt，可能需要手动合并。换句话说，最后的A'看起来像什么，不仅取决于A和A^，还取决于A'将降落的分支B。

---

我想确定我的理解是否正确，因为这一部分让我困惑了很长时间。

你是对的。正如我喜欢说的，从技术上讲，cherry pick是一种合并操作，作为动词合并

大多数Git用户很快就会熟悉

Git merge

命令。merge命令可以运行这个合并操作，这个合并是一个动词。它还可以生成merge-commit，它使用单词merge作为修饰名词commit的形容词。短语merge commit通常缩写为merge，它使用单词merge作为名词。重要的是不要将此merge混淆为名词，即具有merge类型的commit与生成它的进程：merging的动作，merge作为动词，即使

git merge

两者都做（在某些情况下）。将这些想法分开很重要的原因是，其他Git命令执行操作，将merge作为动词部分，而从不进行merge提交。git cherry pick命令就是这样一个命令

理解常规合并 不过，要理解将merge作为动词操作进行合并意味着什么，我认为从

gitmerge

的功能开始是很有帮助的。进行合并的过程，如

git checkout branch1；git merge branch2

，首先需要找到一个合并基提交，这样每个合并都有三个输入

让我们假设有两个不同的程序员在一个项目上工作。按照传统，我们假设程序员A叫Alice，程序员B叫Bob。Alice和Bob从同一个存储库和分支开始，最终彼此共享他们的新提交。最初的分支（可能是

master

）是一个简单的线性提交序列，右侧是较新的提交：

...--F--G--H   <-- master

Bob还克隆存储库，以便通过H进行提交，并创建他的分支

Bob

。在这一分支上，他做出了两项承诺：

...--F--G--H   <-- origin/master
            \
             K--L   <-- bob

控制这个存储库的人可以

git签出alice；git合并bob

，或git checkout-b合并alice；git merge bob。只是为了好玩，让我们做后者。我们不会费心去画

master

（但是名称仍然存在，仍然指向commit

H

）

您可以使用

--theres

从另一个提交引用插槽3中的文件。插槽1中没有文件的速记（尽管可能应该有：

--base

）

但是，对于所有没有冲突的文件，Git成功地合并了Alice的更改和Bob的更改，或者只接受Alice的文件（Bob没有更改），或者只接受Bob的文件（Alice没有更改）。或者，对于大多数文件来说，通常情况下，每个文件的所有三个副本都会合并base、Alice和Bob-all，因为没有人更改任何内容，在这种情况下，文件的任何副本都可以。这些成功合并的文件，连同Alice和Bob在基础中的更改组合在一起，适用于新的合并提交，它们进入工作树和索引/暂存区域，由Git自动组合

（请注意，Alice和Bob也可能进行了相同的更改，例如，修复注释中的键入错误。在这种情况下，Git只复制了其他重复更改的一个副本。此复制操作不被视为冲突。）

这就完成了该过程的“作为动词合并”部分。然后，

git merge

命令要么因为发生冲突而停止，要么继续以形容词merge commit的形式进行合并。如果Git因冲突而停止，则由您来修复Git在工作树和索引中留下的混乱，然后通过执行合并提交来完成该过程，方法是运行

Git merge--continue

或

Git commit

（两者都注意到他们正在完成冲突的合并，并执行最终的合并提交）. 我们可以在这里得出：

             I--J   <-- alice
            /    \
...--F--G--H      M   <-- merged (HEAD)
            \    /
             K--L   <-- bob

请注意，我在这里调用分支

branch

，以及commit

B

，因为我喜欢使用这些单字母替代来进行commit散列。正如你在问题中所做的那样，我已经打电话给

A

的父母

A'

当我们运行

git签出分支

时，它将我们的

头

附加到名称

分支

，并将提交

B

提取到我们的索引和工作树中。现在，我们可以像往常一样，在

分支

的顶端查看并使用commit

B

中的文件

然后，当我们运行

git时，选择A

——直接给出

A

的散列，或者使用查找commit

A

的名称或相对表达式——git同时定位commit

A

和commit

A'

。提交

A'

只是

A

的父级。它必须是唯一的父级：如果commit

A

是一个合并，

git cherry pick

拒绝选择其多个父级中的任何一个，并向我们提供一条错误消息，说明我们必须自己选择该父级（使用

-m

选项）。如果我们手动选择父级，例如，

git cherry pick-m 1 A

，则cherry pick使用我们选择的父级，但通常我们选择非合并

...--F--G--H   <-- origin/master
            \
             K--L   <-- bob

             I--J   <-- alice
            /
...--F--G--H   <-- master
            \
             K--L   <-- bob

             I--J   <-- alice, merged (HEAD)
            /
...--F--G--H
            \
             K--L   <-- bob

git checkout --ours path/to/file.ext

             I--J   <-- alice
            /    \
...--F--G--H      M   <-- merged (HEAD)
            \    /
             K--L   <-- bob

...--o--o--...--A'--A--o--o--o   <-- somebranch
            \
             o--o--B   <-- branch