git cherry-pick操作

使用场景：

公司开发android MTK平台，MTK源码迭代，我司需要把之前的改动导入新源码中，新源码是以新分支的形式更新，故此使用git cherry-pick指令把旧分支的改动同步更新到新源码分支上

git cherry-pick命令的常用配置项如下：

（1）-e，--edit

打开外部编辑器，编辑提交信息。

（2）-n，--no-commit

只更新工作区和暂存区，不产生新的提交。

（3）-x

在提交信息的末尾追加一行(cherry picked from commit ...)，方便以后查到这个提交是如何产生的。

（4）-s，--signoff

在提交信息的末尾追加一行操作者的签名，表示是谁进行了这个操作。

（5）-m parent-number，--mainline parent-number

如果原始提交是一个合并节点，来自于两个分支的合并，那么 Cherry pick 默认将失败，因为它不知道应该采用哪个分支的代码变动。

-m配置项告诉 Git，应该采用哪个分支的变动。它的参数parent-number是一个从1开始的整数，代表原始提交的父分支编号。

$ git cherry-pick -m 1 <commitHash>

上面命令表示，Cherry pick 采用提交commitHash来自编号1的父分支的变动。

一般来说，1号父分支是接受变动的分支（the branch being merged into），2号父分支是作为变动来源的分支（the branch being merged from）。

 冲突解决：

如果操作过程中发生代码冲突，Cherry pick 会停下来，让用户决定如何继续操作。

（1）--continue

用户解决代码冲突后，第一步将修改的文件重新加入暂存区（git add .），第二步使用下面的命令，让 Cherry pick 过程继续执行。

$ git cherry-pick --continue

（2）--abort

发生代码冲突后，放弃合并，回到操作前的样子。

（3）--quit

发生代码冲突后，退出 Cherry pick，但是不回到操作前的样子

分支代码转移提交：

提交一个commit：

$ git cherry-pick <HashA>

多个提交commit：

$ git cherry-pick <HashA> <HashB>

上面的命令将 A 和 B 两个提交应用到当前分支。这会在当前分支生成两个对应的新提交。

如果想要转移一系列的连续提交，可以使用下面的简便语法。

$ git cherry-pick A..B 

上面的命令可以转移从 A 到 B 的所有提交。它们必须按照正确的顺序放置：提交 A 必须早于提交 B，否则命令将失败，但不会报错。

注意，使用上面的命令，提交 A 将不会包含在 Cherry pick 中。如果要包含提交 A，可以使用下面的语法。

$ git cherry-pick A^..B 

报错解决： 

场景：A分支的提交（hash C） cherry-pick 到B分支

1.合并冲突

自动合并 release/vendor/A.java
冲突（内容）：合并冲突于release/vendor/A.java

原因：B分支的release/vendor/A.java文件与A分支hash C之前的文件存在差异

解决：A分支会退之hash C之前的版本，然后将A分支release/vendor/A.java提交到B分支然后执行cherry-pick hash C

2.git cherry-pick hash D
fatal: bad object hash D

原因：B分支代码本地没有hash D提交

解决：B分支执行 git pull  本地同步hash D提交，然后执行cherry-pick commit