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
上面命令表示，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
多个提交commit：
$ git cherry-pick
上面的命令将 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