Eclipse上GIT插件EGIT使用手册之九_Rebase和Merge的区别
jopen
13年前
<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操作更复杂，冲突的概率也更高，并且不是按照时间顺序记录。