共计 1385 个字符，预计需要花费 4 分钟才能阅读完成。
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…