Git 中 merge 和 rebase 的区别

参考: https://developer.aliyun.com/article/652579

简介： $ git pull --rebase和$ git pull区别 是git fetch + git merge FETCH_HEAD的缩写，所以默认情况下，git pull就是先fetch,然后执行merge操作，如果加-rebase参数，就是使用git rebase代替git merge 。

$ git pull --rebase和$ git pull区别
是git fetch + git merge FETCH_HEAD的缩写，所以默认情况下，git pull就是先fetch,然后执行merge操作，如果加-rebase参数，就是使用git rebase代替git merge 。更新本地仓库

merge 和 rebase
merge 是合并的意思，rebase是复位基底的意思。
现在我们有这样的两个分支,test和master，提交如下：

1
2
3
     D---E test
    /
A---B---C---F master

在master执行git merge test然后会得到如下结果：

1
2
3
     D--------E
    /          \
A---B---C---F---G    test , master

在master执行git rebase test,然后得到如下结果：

1
A---C---D---E---C `---F` test , master

可以看到merge操作会生成一个新的节点，之前提交分开显示。而rebase操作不会生成新的节点，是将两个分支融合成一个线性的操作。

通过上面可以看到，想要更好的提交树，使用rebase操作会更好一点，这样可以线性的看到每一次提交，并且没有增加提交节点。
在操作中。merge操作遇到冲突时候，当前merge不能继续下去。手动修改冲突内容后，add 修改，commit 就可以了
而rebase操作的话，会中断rebase，同时会提示去解决冲突。解决冲突后，将修改add后执行git rebase -continue继续操作，或者git rebase -skip忽略冲突。

使用场景

比如rebase,你自己开发分支一直在做,然后某一天，你想把主线的修改合到你的分支上,做一次集成,这种情况就用rebase比较好.把你的提交都放在主线修改的头上 如果用merge，脑袋上顶着一笔merge的8,你如果想回退你分支上的某个提交就很麻烦

还有一个重要的问题,rebase的话,本来我的分支是从3拉出来的,rebase完了之后,就不知道我当时是从哪儿拉出来的我的开发分支 同样的,如果你在主分支上用rebase, rebase其他分支的修改,是不是要是别人想看主分支上有什么历史,他看到的就不是完整的历史课,这个历史已经被你篡改了

所以总结:

  • 不要在公共分支使用rebase
  • 本地和远端对应同一条分支,优先使用rebase,而不是merge