使用git向主干分支合并代码通常采用两种方式：第一种是merge，第二种是利用BeyondCompare等工具进行比对，将差异合并到主干；
通过merge合并代码出现冲突时，并不清楚谁的修改和谁的修改发生了冲突，在没有了解冲突背景的情况下解决冲突可能引入问题；
利用BeyondCompare等比对工具直接将代码合入会丢失大量的commit信息，影响后续代码的可追溯性。
个人建议采用git cherry-pick进行代码合并；首先在自己的开发分支上进行开发调试，验证通过后进行代码提交整理，识别功能性提交和调试性提交，将调试性提交与之前的功能性提交进行commit合并，最后将整理后的commit通过git cherry-pick合并到主干分支，具体步骤如下：
1.从主线分支master拉取自己的开发分支self_develop；
2.在自己的开发分支self_develop上进行开发、调试、验证，直至当前小功能点验证通过；
3.在自己的开发分支self_develop上执行git log >gitlog.txt, 将commit信息导出到gitlog.txt中，如下所示（请无视中文commit log，这是自己的LaTex文档库😀）；
4.使用notepad++等文本编辑器，过滤出以commit起始的commit id信息，从中截取拉取开发分支时的base以及后续开发提交部分，如下所示：
5.利用批量替换将"commit"替换为"git cherry-pick"；拉取分支时的base对应的commit修改为"git reset --hard", 如下所示：
5.将上述文本贴到excel表格中，之前预留一列，通过拖动的方式进行自动编号：
6.在excel中按A列降序排列，进行反转：
7.将反转后的信息再拷贝到文本编辑器进行整理，识别哪些是开发功能提交，哪些是为了解决编译错误等进行的调试性提交；调试性提交通过rebase命令合并到之前的开发功能提交中：
8.从自己的开发分支self_develop再拉取一个用于合并的分支self_develop_formerge，执行步骤7中的命令；
首先将self_develop_formerge的代码回退到拉取开发分支时的base，然后顺序执行git cherry-pick添加代码；
最好逐条执行，便于遇到冲突及时解决，git rebase -i HEAD^^^操作类似vim，有几个^就是合并几次提交。
注意：解决冲突时，尽量保留如下冲突示例中的蓝色部分代码，否则后续cherry-pick如果涉及同一部分修改可能持续出现冲突，如果实在需要保留红色部分代码，可以等所有cherry-pick都执行完后，再进行最后一次commit修改回来。
+<<<<<<< HEAD
code old //代码库中已有代码
+======= //冲突分界线
code new //从你的develop分支cherry-pick过来的代码
+>>>>>>> e2316cf... add some function
9.所有命令执行完后，代码整理结束；再按照步骤3--步骤8同样的方法将整理后的功能性提交合并到主干分支master；
10.步骤9结束后代码就合并完了，需要进一步确认一下合并的代码是否有遗漏，执行一下4条命令即可：
git diff d6129be2 d9414e16 >diff_of_master //d6129be2 d9414e16分别是主干分支合并前的最后一次提交和合并代码后的最后一次提交
git diff 00322967 2dc90513 >diff_of_develop //00322967 2dc90513分别是调试分支拉取时的base和完成功能调试验证的最后一次提交
diff diff_of_master diff_of_develop
rm diff_of_master diff_of_develop
如果第三条命令的输出结果没有实际代码的差异（可能有一些commit消息差异，比如同样的修改，在调试分支和主干分支修改的代码行数可能不一样都会体现在diff文件中，这些差异无影响可以忽略），说明代码合并没有遗漏，可以放心push到公共代码库了。
来源：oschina
链接：https://my.oschina.net/u/4346667/blog/3593379