这么久以来不管是更新当前分支代码，还是合并代码，都是使用的merge，但也知道有rebase的操作，就是不理解其究竟有什么区别，且merge用了这么久没出过啥问题，就没深究过rebase。现在抽空出来，研究一下，实际rebase的使用场景还是挺多，而且这些场景下使用rebase的姿势也要比merge正确。
上游和下游：一直有一个固定上游，就是master分支，所有分支向上追溯的根源都是master，所以上游和下游是相对的，上游就是从当前分支还新拉了一个分支，那当前分支就是上游，下游就是你从其他分支拉的最新分支。
现在有三个分支，master、merge_test、rebase_test分支来进行演示。
master更新文件，push， 提交日志如下图：
merge_test使用merge更新master分支的代码：因为下游分支一直在提交新的改动代码，所以想要更新上游分支时，如果使用merge的话，那会多出一行merge的提交记录。
虽然没什么影响，中间插入这么一条记录，看起来时间线根本不好看。merge_test分支查看git日志如下图：
rebase_test使用rebase更新master分支的代码：此时如果我们使用rebase来更新master的代码到开发分支，就是所谓的“变基”，将master的提交记录，全部迁移到当前开发分支，当前分支就是以master为基础重新更新的分支。就像是当时从master拉出来时一样，在开发分支会有创建分支之前，在上游分支的git提交记录。rebase_test分支查看git日志如下图，就不会存在上面merge操作更新后，多的那一行记录。
使用 rebase 之后，如果直接使用 git push origin rebase_test 发现是不好使的，会有问题提示说明，相对远程 rebase_test 分支而言，本地仓库的rebase_test分支的“基底”已经变化了，直接 push 是不行的，所以确保没有问题的情况下必须使用 --force 参数才能提交，这也就是官方对 rebase 作为 “变基” 的解释（个人观点）
idea中在rebase后push会有以下提示，再次点击rebase即可：
rebase了，因为下游全是基于上游开发的，所以上游使用merge即可。--rebase 参数更新当前分支代码时，会有两种方式：
merge来pull更新代码，也会发现每次pull后，会多出一行提交记录：Merge remote-tracking branch ‘origin/merge_test‘ into merge_testrebase来进行更新当前分支的代码。rebase 就感觉所有人都在同一条直线上开发一样，历史提交线会很清晰。以上是结合多个博客总结的
参考原文链接：https://zhuanlan.zhihu.com/p/34197548、
原文：https://www.cnblogs.com/qukun/p/14435309.html