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