驾驭git merge——git merge的规范化操作

Posted leituhaomo

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了驾驭git merge——git merge的规范化操作相关的知识,希望对你有一定的参考价值。

  这两天负责将一个开发了较长时间,代码量数万行的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!

以上是关于驾驭git merge——git merge的规范化操作的主要内容,如果未能解决你的问题,请参考以下文章

git merge 一个文件名大小写更改后的分支 失败

[git] git merge 和 git merge --no-ff

如何避免git merge branch

git merge原理(递归三路合并算法)

git merge用法

闲谈 git merge 与 git rebase 的区别