1.Cherry Pick与Create Patch的区别

Cherry Pick与Create Patch的区别

结论
实验
- 场景1：应用时无冲突
- 场景2：应用时产生冲突
- - 使用cherry pick
  - 使用patch
- 场景3：产生冲突，并且有其他文件的变更
原理

结论

1.应用无冲突时cherry pick与patch一样，只应用变更的内容；
2.区别在于cherry pick解决冲突时相会对冲突文件进行分支合并（每个commit的引用都可当作分支），而patch只应用变更的内容。
2.1.cherry pick解决冲突时只引用提交中的文件内容，不是全部分支合并。
我们来进行三组实验，分别验证这3个结论。

实验

场景1：应用时无冲突

从master上切出两个分支master-01,master-02。
目标：master-01分支应用master-02的一个提交
步骤：
在master-02分支上提交两次。
在master-01分支上引用master-02的第二次提交，发现引用的是第二次提交的内容，第一次提交的内容没有被引用。验证了论点1
【master-02分支的两次提交】：

【master-01 cherry pick之后：】

场景2：应用时产生冲突

目标：master-03分支应用master-02的一个提交
步骤：
master-03 提交一个更改，如图1
master-02 提交一个更改(这个更改不想被master-03引用)，在与master-03提交的同一处再次提交了一个更改（制造冲突），如图2

图1：

图2:

使用cherry pick

在master-03分支上使用 mater-02的最后一次更改
结果：解决冲突时会合并文件。把整个文件的更改都引用过来了。

使用patch

场景3：产生冲突，并且有其他文件的变更

从master上切出两个分支master-01,master-02。
目标：master-01分支应用master-02的一个提交
步骤：
在master-01分支上进行一次提交；
在master-02分支上提交两次；
在master-02分支上制造一个与master-01分支产生冲突的提交；
在master-01分支上引用master-02的第三次提交，发现冲突时只引用当前提交包含的文件，符合预期，验证了论点3
【master-01进行一次提交】：

【master-02分支的三次提交】：

【master-01 cherry pick之后：】

原理

cherry pick引用的是一个commit，解决冲突时会将包含的文件当作分支进行合并。
patch只是一个提交的变更记录，解决冲突时会当作本地修改进行合并。