git rebase 和 git merge 使用区别

一直没用过git rebase，最近听一位后端同学建议用git rebase代替git merge，于是想仔细研究一下这两者的区别。

什么是rebase？

你可以把git rebase理解成——“重新设置基线”，将你的当前分支重新设置开始点。这时你才能知道你当前分支和需要比较的分支之间的差异。

官方解释：https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%8F%98%E5%9F%BA

git rebase 和 git merge 有什么区别？

（1）rebase

rebase会把你当前分支的commit放到公共分支的最后，所以叫做变基。就如同你从公共分支又重新拉出来这个分支一样。

举例：如果你从master拉了个feature分支出来，然后你提交了几个commit，这时刚好有其他人把他开发的东西合并到master了，这时master就比你拉分支的时候多了几个commit，如果这时你git rebase master的话，就会把你当前的几个commit，放到那个人commit的后面。

（2）merge

merge会把公共分支和你当前的commit合并在一起，形成一个新的commit提交。

merge

注意项

1、不要在公共分支使用rebase

因为往后放的这些commit都是新的，这样其他从这个公共分支拉出去的人，都需要再rebase，相当于你rebase东西进来，就都是新的commit了。

2、merge和rebase实际上只是使用场景不一样，本地和远端对应同一条分支，优先使用rebase而不是merge

比如rebase，你自己开发分支一直在做，然后你想把主线的修改合到你的分支上，做一次集成，这种情况就用rebase比较好，把你的提交都放在主线修改的头上。

如果用merge，脑袋上顶着一笔merge的8，你如果想回退你分支上的某个提交就很麻烦，还有一个重要的问题，rebase的话，本来我的分支是从3拉出来的，rebase完了之后，就不知道我当时是从哪儿拉出来的我的开发分支。

同样的，如果你在主分支上用rebase，rebase其他分支的修改，如果别人想看主分支上有什么历史，他看到的不是完整的历史，这个历史已经被你篡改了。