0
点赞
收藏
分享

微信扫一扫

再谈git merge

之前写过一个关于git merge的文章,但是总觉得的差了些什么。于是决定在写一次,用以更新这两天的对git merge的新感悟。

merge的原理

虽然之前文章有详细介绍,但是这里还是有必要重提下,因为这是使用和理解的核心点。重要的事情说三遍,所以原理新说觉得也是很必要的。merge采用三路合并,所以社区中有人提到merge和时间或者commit节点顺序,又或者谁发起等有关,这里要郑重说明merge与时间顺以及谁merge谁没有关系。因为merge的三路比较实际比较的是两个将要merge到一起的HEAD以及两者的公共祖先commit节点。所以这期间两个分支的变更commit节点是不相关的。因此,这里可以理解为是三个总commit节点的比较。当然了这两者的HEAD要泛指两个分支分别到公共commi之间的所有变更点。

merge易错点

上一篇关于git merge的文章中,错将出现问题的原因归因于merge,其实,是作者的失误,以及当时自身知识水平的欠缺。其实这里准确的说是人为因素造成的。因为如果主分支不管理混乱的话,是不会出现合并丢失代码的情况的。导致这一切发生的是merge的滥用导致的。例如说A分支mergeB分支(B分支在A分支 commit为1的节点被创建),他们的公共节点是原本是1,但是如果其中B反向合并A分支的话(这里比如commit为2的节点发生)那么他们的公共节点就会变成2.这样就为接下来两者的三路合并留下了隐患,此外,这次反合的发生在commit中也会造成代码片段修改的丢失。

操作说明

埋下隐患的操作如下:

// A分支下:
> git co -b B
> git add .
> git commit -m 'feat: your Acode'
> git push

// B 分支下
> git add .
> git commit -m 'feat: your Bcode'
> git merge A

结束语

本文解决了之前关于git merge理解不透彻的点,以及发现merge丢失代码的隐患操作。希望通过这个加强版的说明,让大家明白git merge自身的合并规则是没有问题的。但在使用中要注意反合的问题。

一尘不染,静待疫散,不负阳光,不负爱。

举报

相关推荐

0 条评论