发布于 2014-12-23 04:07:11 | 662 次阅读 | 评论: 0 | 来源: PHPERZ
EGit Eclipse上的Git插件
Git 作为进来最流行的分布式版本控制软件来说应用的十分广泛。EGit就是一款Eclipse上的Git插件。
本文是Eclipse上GIT插件EGIT使用手册的第十篇为大家讲解的是Rebase和Merge的区别,感兴趣的同学参考下。
Rebase和Merge操作最终的结果是一样的,但是实现原理不一样。
从上面的MairoBro例子可以知道pull大概对历史记录进行了怎样的合并操作,其实默认pull的操作就是一个分支的merge操作,如下图重现一下:
Mairo弟弟的提交记录如下:
Mairo哥哥的提交记录如下:
首先是Mairo弟弟把更新push到服务器,这样服务器端的记录就和Mairo弟弟本地的记录是一样的,接着Mairo哥哥执行pull操作,现在分析下pull是如何操作的。
l pull默认就是先把服务器端的最新记录更新到本地的Remote Tracking中对应的mirror分支
l 接着对Local的mirror分支和Remote Tracking的mirror分支进行merge操作
Merge操作后的结果就是会新增加一个merge记录节点,如下所示:
从上图可以看出,mushroomA是在mushroomB之前的,这个时间关系不取决于谁先执行push,而取决于本地仓库中谁先执行commit。所以merge会按照时间顺序严格的记录每一次commit。
接下来看看rebase,其实rebase也是把两个分支进行合并的操作,当Mairo弟弟push更新后,服务器端的mirror分支的历史如下:
Mairo哥哥本地的历史如下:
现在Mairo哥哥不是执行merge操作,而是执行rebase操作,最后结果如下:
很明显的区别是没有出现分支的记录,而且注意到mushroomA*,请注意这个记录和mushroomA不是同一个记录,我们先分析下rebase操作下,Mairo哥哥的历史记录都做了哪些变化:
l 先将当前分支的更新部分保存到临时区域,而当前分支重置到上一次pull的记录
l 然后将服务器端的更新添加到当前分支,此时当前分支和服务器端分支是一样的
l 最后将原分支的更新部分mushroomA提交到当前分支的后面,就是要在mushroomB的后面添加mushroomA的更新,当然此时更新记录已经不是之前的mushroomA了,如果出现冲突则使用对比工具解决冲突,最后记录变成mushroomA*。
如果Mairo哥哥提交过mushroomA1、mushroomA2、mushroomA3,那么执行rebase后会对mushroomA1、 mushroomA2、mushroomA3分别顺序执行上图所示的合并,最后记录为mushroomA1*、mushroomA2*、 mushroomA3*。很显然rebase操作更复杂,冲突的概率也更高,并且不是按照时间顺序记录。