一、git rebase解决什么问题
git merge 命令存在两种情景
1、 fast-forward （以后分支的base与master最新commit统一）
2、 no-fast-forward （以后分支的base与master最新commit不统一）
git rebase就是将no-fast-forward变成fast-forward
二、时间轴比对
应用rebase
应用merge
三、场景
上游（dev）分支更新上游（master）分支内容，应用rebase
上游（master）分支合并上游（dev）分支内容，应用merge
以后分支更新操作：git pull origin dev --rebase
以后分支rebase之后：git push origin dev --force
git rebase 个别只用于非master分支，比方在dev分支中执行git rebase master，master分支始终作为基准分分支
git merge 能够在任何分支merge其余分支，比方在master中merge dev，也能够在dev分支中merge master
另一种场景：
fork我的项目，提交pr更多的时候采纳git rebase
四、rebase劣势
rebase提供一套清晰的代码历史。
在咱们以后的oceanus我的项目开发中，分支只存在于迭代的开发中，开发实现之后个性分支保留一段时间之后就会被删除，所以采纳merge合并代码的网格记录对于咱们来说，其实没什么价值。
另外最近一段时间存量迭代较多，导致一个个性分支公布之后，每个存量迭代对应的分支代码都会进行一次merge，会无形之中增加很多 merge branch master into ... 记录。
merge合并代码是按commit提交的工夫来解决，所以Merge branch 'v4.6-subnet' into v4.6.0-savepoint相似的提交与理论的commit可能相隔很远，而且commit与其余分支的commit交错在一起，导致某一个实现性能开发的代码提交记录被宰割。
rebase因为存在commit refresh，所以commit在提交之后追加到上游分支，成线形记录。
优质文章举荐：
https://zhuanlan.zhihu.com/p/...