Eclipse上GIT插件EGIT使用手册之九_Rebase和Merge的区别

jopen 9年前
     <p>Rebase和Merge操作最终的结果是一样的,但是实现原理不一样。</p>    <p>从上面的MairoBro例子可以知道pull大概对历史记录进行了怎样的合并操作,其实默认pull的操作就是一个分支的merge操作,如下图重现一下:</p>    <p>Mairo弟弟的提交记录如下:</p>    <p><img alt="Eclipse上GIT插件EGIT使用手册之九_Rebase和Merge的区别 " src="https://simg.open-open.com/show/dc58aecb37b12548e4bbe8952b4f93c0.bmp" width="307" height="42" /></p>    <p>Mairo哥哥的提交记录如下:</p>    <p><img alt="Eclipse上GIT插件EGIT使用手册之九_Rebase和Merge的区别 " src="https://simg.open-open.com/show/de1a1fb820134b85ec3b57986a15eb78.bmp" width="307" height="42" /></p>    <p>首先是Mairo弟弟把更新push到服务器,这样服务器端的记录就和Mairo弟弟本地的记录是一样的,接着Mairo哥哥执行pull操作,现在分析下pull是如何操作的。</p>    <p>l  pull默认就是先把服务器端的最新记录更新到本地的Remote Tracking中对应的mirror分支</p>    <p>l  接着对Local的mirror分支和Remote Tracking的mirror分支进行merge操作</p>    <p><img alt="Eclipse上GIT插件EGIT使用手册之九_Rebase和Merge的区别 " src="https://simg.open-open.com/show/bd7c3f39ddd45390afc50b7603ae79ac.png" width="205" height="140" /></p>    <p>Merge操作后的结果就是会新增加一个merge记录节点,如下所示:</p>    <p><img alt="Eclipse上GIT插件EGIT使用手册之九_Rebase和Merge的区别 " src="https://simg.open-open.com/show/96cc44965a831f9d92e023c8db0bfa20.bmp" width="493" height="152" /></p>    <p>从上图可以看出,mushroomA是在mushroomB之前的,这个时间关系不取决于谁先执行push,而取决于本地仓库中谁先执行commit。所以merge会按照时间顺序严格的记录每一次commit。</p>    <p>接下来看看rebase,其实rebase也是把两个分支进行合并的操作,当Mairo弟弟push更新后,服务器端的mirror分支的历史如下:</p>    <p><img alt="Eclipse上GIT插件EGIT使用手册之九_Rebase和Merge的区别 " src="https://simg.open-open.com/show/dc58aecb37b12548e4bbe8952b4f93c0.bmp" width="307" height="42" /></p>    <p>Mairo哥哥本地的历史如下:</p>    <p><img alt="Eclipse上GIT插件EGIT使用手册之九_Rebase和Merge的区别 " src="https://simg.open-open.com/show/de1a1fb820134b85ec3b57986a15eb78.bmp" width="307" height="42" /></p>    <p>现在Mairo哥哥不是执行merge操作,而是执行rebase操作,最后结果如下:</p>    <p><img alt="Eclipse上GIT插件EGIT使用手册之九_Rebase和Merge的区别 " src="https://simg.open-open.com/show/c7976c6e808fa799d7564e96df987380.bmp" width="455" height="76" /></p>    <p>很明显的区别是没有出现分支的记录,而且注意到mushroomA*,请注意这个记录和mushroomA不是同一个记录,我们先分析下rebase操作下,Mairo哥哥的历史记录都做了哪些变化:</p>    <p>l  先将当前分支的更新部分保存到临时区域,而当前分支重置到上一次pull的记录</p>    <p><img alt="Eclipse上GIT插件EGIT使用手册之九_Rebase和Merge的区别 " src="https://simg.open-open.com/show/df76f35c2e0cf409b843bb21c325f01c.bmp" width="175" height="99" /></p>    <p>l  然后将服务器端的更新添加到当前分支,此时当前分支和服务器端分支是一样的</p>    <p><img alt="Eclipse上GIT插件EGIT使用手册之九_Rebase和Merge的区别 " src="https://simg.open-open.com/show/d572f92cc3f59efd8b6df8e1ef4ff29b.bmp" width="307" height="99" /></p>    <p>l  最后将原分支的更新部分mushroomA提交到当前分支的后面,就是要在mushroomB的后面添加mushroomA的更新,当然此时更新记录已经不是之前的mushroomA了,如果出现冲突则使用对比工具解决冲突,最后记录变成mushroomA*。</p>    <p><img alt="Eclipse上GIT插件EGIT使用手册之九_Rebase和Merge的区别 " src="https://simg.open-open.com/show/c7976c6e808fa799d7564e96df987380.bmp" width="455" height="76" /></p> 如果Mairo哥哥提交过mushroomA1、mushroomA2、mushroomA3,那么执行rebase后会对mushroomA1、 mushroomA2、mushroomA3分别顺序执行上图所示的合并,最后记录为mushroomA1*、mushroomA2*、 mushroomA3*。很显然rebase操作更复杂,冲突的概率也更高,并且不是按照时间顺序记录。