此篇只会来介绍rebase和merge的区别
rebase
下面我们进行一个小练习来练习一下rebase
看一下题目要求：
- 共有三个特性分支 ——
side1side2和side3 - 将这三分支按顺序推送到远程仓库
- 因为远程仓库已经被更新过了，所以我们还要把那些工作合并过来
执行命令：git fetch
执行命令：git rebase o/master side1
执行命令：git rebase side1 side2
执行命令:git rebase side2 side3
执行命令：git rebase side3 master
执行命令:git push
好了，我们已经完成了，现在我们可以看到我们本地和远程都已经是线性的，美滋滋
merge
下面我们来试一下用merge来解决这个问题
执行命令：git fetch
执行命令：git checkout o/master
执行命令：git merge side1
执行命令：git merge side2
执行命令：git merge side3
执行命令：git checkout master
执行命令：git merge C11
执行命令：git push
好了，现在我们也用merge完成了
总结：
为了 push 新变更到远程仓库，你要做的就是包含远程仓库中最新变更。意思就是只要你的本地分支包含了远程分支（如 o/master）中的最新变更就可以了，至于具体是用 rebase 还是 merge，并没有限制。
那么既然没有规定限制，为何前都在着重于 rebase 呢？为什么在操作远程分支时不喜欢用 merge 呢
在开发社区里，有许多关于 merge 与 rebase 的讨论。以下是关于 rebase 的优缺点：
优点:
- Rebase 使你的提交树变得很干净, 所有的提交都在一条线上
缺点:
- Rebase 修改了提交树的历史
比如, 提交 C1 可以被 rebase 到 C3 之后。这看起来 C1 中的工作是在 C3 之后进行的，但实际上是在 C3 之前。
一些开发人员喜欢保留提交历史，因此更偏爱 merge。而其他人可能更喜欢干净的提交树，于是偏爱 rebase。仁者见仁，智者见智。
