标签：target 现在 方式 标记 targe rebase 冲突 color 校验
这两天负责将一个开发了较长时间，代码量数万行的C语言项目（A项目）的代码分支合并到主线。由于之前参与过一些其他项目分支收编时采用git merge引入问题的修改，个人从心理上对git merge有所抵触。有个动图形象描述了git merge使用不当带来的灾难：
鉴于上述原因，平时从个人的调试分支向项目公共分支合并commit时一般也采用git cherry-pick的方式（详见另一篇博客）,以尽量保持项目分支在通过gitk查看时是一条直线。原计划此次合入也采用git cherry-pick的方式：先将项目的git log导出到文件中，然后按照下图利用标记分段的方式过滤出我们项目开发的提交，再通过cherr-pick将这些提交合并到主线。
///begin1 commit xxxxxxxxxx commit xxxxxxxxxx commit xxxxxxxxxx ///end1 commit xxxxxxxxxx commit xxxxxxxxxx ///begin2 commit xxxxxxxxxx commit xxxxxxxxxx commit xxxxxxxxxx ///end2 commit xxxxxxxxxx commit xxxxxxxxxx
。。。。。。
但是由于开发分支历史上与其他项目的分支进行过多次合并，A项目与其他项目的commit相互穿插，很难进行标记分段；不得已只能采用git merge。既然git merge是最常用的命令而非洪水猛兽，造成问题的最大因素还是人，引入的问题多数因为使用不当。可以通过规范化操作避免问题，自己稍微梳理了下能够尽量避免问题的操作步骤：
目标：将develop分支上的提交合并到master分支。
步骤：
1.在master分支下执行git checkout -b master_for_merge创建并切换到用于合并的master_for_merge临时分支;
2.执行命令git merge develop将develop分支的内容合并到master_for_merge分支；
3.直接执行git add .和git commit -m "merge with conflict"两条命令生成一次提交;
这里需要注意，通常将develop分支合并过来是会产生冲突的，但是不建议现在修改，本来代码合并过来差异就很大，此时修复冲突如果不慎修改了其他地方引入问题，很难通过代码比对发现。
4.解决冲突:
在代码目录下执行grep -nr "<<<< HEAD" ./找到冲突的地方进行修改，修改完后执行git add .和git commit -m "fix conflict"两条命令生成一次提交;这样通过git show HEAD可以清楚的看到我们为修改冲突改了哪些内容；
至此用于合并代码的master_for_merge分支已经准备好了，为了进一步确认合并没问题我们再进行两次校验。
5.执行git diff master master_for_merge, 确认所有的差异都是develop分支上开发的内容，确认未合入develop分支外的其他内容;
6.执行git diff develop master_for_merge, 确认所有的差异都不是develop分支上开发的内容，确保合入不遗漏;
7.将步骤3生成的"merge with conflict"和步骤4生成的"fix conflict"两个commit通过git rebase的方式合并为一次commit.
8.测试验证master_for_merge分支代码，如果没问题在master分支下执行git merge master_for_merge就完成代码合并了.
按上述步骤merge的主要目的是可以通过步骤4,5,6查看冲突解决方式以及进一步确认代码合入是否有错和遗漏。
最后，如果可以，建议首选方式还是采用cherry-pick！
标签：target 现在 方式 标记 targe rebase 冲突 color 校验
原文地址：https://www.cnblogs.com/leituhaomo/p/12126508.html
