概念
Rebase 和 merge 都被设计用来将变更从一个分支整合到另一个分支，但是它们的实现方式却不同。
下面假如我们有如下提交，merge 会将两个分支的代码合并，而 rebase 会将 feature 分支上所有的变更在 master 分支上重新应用一遍：
- 当你将 feature 分支 rebase 到 master 时，实际上是将 feature 的 base 移动到了 master 分支的终点，所以 rebase 中文叫变基。（想象上图平移了两条线段）
- merge 则是拿 feature 分支中的结果，合并到 master 分支，这个过程中只有 master 分支改变了，feature 分支保持不变
- merge 的时候会产生一个新的 commit
Merge 的优与劣
优点
- 简单易用，易于理解
- 保留原始提交记录和源分支
- 源分支上的提交与其他分支分离，这会方便你浏览并且合并到其他分支
- 保留你的提交历史，保证提交历史在语义上的准确性
缺点
- 提交历史 可能会变得很乱，尤其是很多人同时开发与合并分支时
- 使用
git bisect调试将变得困难
Rebase 的优与劣
优点
- 代码历史简洁，线性，可读性强
- 相比众多功能分支来说，只有一个分支，管理起来更加方便
- 简洁的 提交记录 让调试和排查更容易
缺点
- feature 分支变成了一些 commit，不利于体现开发时的场景
Rebase 不适合与
pull requests同时工作，因为你看不出来哪里是别人做的变更。重写了历史记录也不利于团队协作你在使用 rebase 时也应该更加小心
- 在处理 冲突 时需要花费更多的精力，使用 rebase 来合并功能分支，同一个冲突可能需要合并多次。
总结
- 如果有几个开发者同时在 feature 分支上开发，就不推荐使用 rebase，因为 rebase 会掩盖真实的提交场景。相对而言，个人开发更适合使用 rebase。
- 如果你想保留完整的历史记录，就应该使用 merge。记住，Merge 保留历史记录，而 Rebase 改写历史记录
Rebase 可以用来精简一个复杂的历史记录，通过交互式 rebase，你可以去掉不想要的 commit，合并多个 commit 甚至修改 commit 信息。
需要注意的是，由于 rebase 是将 commit 一个一个应用到目标分支，所以在产生冲突时，需要针对 commit 一个一个去解决，而 merge 是将 commit 的最终结果合并到目标分支，所以冲突只需要解决一次即可。而如果有很多冲突的话，撤销一个 rebase 也将会非常困难。
