1.区别
rebase：
也称为变基，会将以后分支的 commit 放到公共分支的最初面。就如同从公共分支又从新拉进去这个分支一样。
举例:如果你从 master 拉了个feature分支进去,而后你提交了几个 commit,这个时候刚好有人把他开发的货色合并到 master 了,这个时候 master 就比你拉分支的时候多了几个 commit,如果这个时候你rebase master 的话，就会把你以后的几个 commit，放到那个人 commit 的前面。
merge：
会把公共分支和你以后的commit 合并在一起，造成一个新的 commit 提交。
一般来说，本地和远端对应同一条分支,优先应用rebase,而不是merge
2.为什么不要在公共分支应用rebase?
因为往后放的这些 commit 都是新的,这样其余从这个公共分支拉出去的人，都须要再 rebase,相当于你 rebase 货色进来，就都是新的 commit 了
- 1-2-3 是当初的分支状态
- 这个时候从原来的master ,checkout进去一个prod分支
- 而后master提交了4.5，prod提交了6.7
- 这个时候master分支状态就是1-2-3-4-5，prod状态变成1-2-3-6-7
- 如果在prod上用rebase master ,prod分支状态就成了1-2-3-4-5-6-7
- 如果是merge
1-2-3-6-7-8
…….. |4-5| 会进去一个8，这个8的提交就是把4-5合进来的提交
3.merge和rebase实际上只是用的场景不一样
比方rebase,你本人开发分支始终在做,而后某一天，你想把主线的批改合到你的分支上,做一次集成,这种状况就用rebase比拟好.把你的提交都放在主线批改的头上
如果用merge，脑袋上顶着一笔merge的8,你如果想回退你分支上的某个提交就很麻烦,还有一个重要的问题,rebase的话,原本我的分支是从3拉进去的,rebase完了之后,就不晓得我过后是从哪儿拉进去的我的开发分支
同样的,如果你在主分支上用rebase, rebase其余分支的批改,是不是要是他人想看主分支上有什么历史,他看到的就不是残缺的历史课,这个历史曾经被你篡改了。
4.如果在master分支上面搞一个新的分支，开发的同时，master有了新增代码，然而须要在新的master下面持续开发，怎么办呢？
1、先把本人写的代码，保留到本地库，而后推送到来近程库（至关重要），而后拉下来近程库，这很重要
2在git命令中输出：git rebase origin/master,这样就会把当初正在开发的分支中曾经写好的代码与最新的master分支的代码交融在一起
3.输出 git status 显示抵触的文件，而后找到那个文件解决抵触，git add 文件名,这样才算解决一个抵触，输出 git rebase --continue ，持续git status ....... 晓得所有的抵触全副解决
（git status如果不显示抵触文件，但又处于rebase状态，输出git rebase --skip)
如果不想解决抵触了，输出 git rebase --abort ，回到最后的状态，后面解决的所有抵触都会复原到以前的状态
4.解决完抵触后，推送到近程库。
参考链接：
https://www.jianshu.com/p/407...
https://git-scm.com/book/zh/v...