merge rebase两个分支合并操作，各有利弊；我们先看看表现吧；
假如master和feature分支如下：
如果我们merge操作；
我们看到 合并时候，作为一个新提交作为一个新节点，head指针移动到最新master分支；
feature分支历史被有效的保留着；
优点
简单易上手
保留了提交历史和时间次序
保留了分支的结构
缺点
提交历史被大量的 merge 提交污染了
我们再看看rebase操作；
我们看到rebase后，原先的feature接接到master原先分支前面；
feature分支信息没了；
具体执行操作是 重新提交每一次的本地变化，如果有冲突，需要先解决冲突；
优点
把复杂的历史变成优雅的提交线
操作单个提交变得很简单（比如，reverting）
避免了庞大的仓库、海量的分支以及烦人的 merge 提交
线性合并清除了中间的无用提交，对于 DevOps 团队来说是个好消息
缺点
Rebase 后 feature 分支间的上下文模糊了
在团队里 rebasing 公共分支是高风险的事
具体使用哪种，其实都是可以的，不管用哪种，根据项目管理来约定；
注意点：
假如使用rebase，一定要遵守rebase黄金法则，共享的public分支不能rebase，
通俗的说，当一个分支是一个人开发处理的，才可以rebase，假如一个分支被多个人共享开发，然后rebase，那就乱套了，处理起来复杂；
------------------------------------------------------------------------------------------------------------------------------
作者： java1234_小锋
出处：https://www.cnblogs.com/java688/p/13418946.html
版权：本站使用「CC BY 4.0」创作共享协议，转载请在文章明显位置注明作者及出处。
------------------------------------------------------------------------------------------------------------------------------