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.解决完冲突后，推送到远程库。