Git merge | rebase
前言
这么久以来不管是更新当前分支代码，还是合并代码，都是使用的merge，但也知道有rebase的操作，就是不理解其究竟有什么区别，且merge用了这么久没出过啥问题，就没深究过rebase。现在抽空出来，研究一下，实际rebase的使用场景还是挺多，而且这些场景下使用rebase的姿势也要比merge正确。
使用 rebase 和 merge 的基本原则
- 下游分支更新上游分支内容的时候使用 rebase
- 上游分支合并下游分支内容的时候使用 merge
- 更新当前分支的内容时一定要使用 --rebase 参数
上游和下游：一直有一个固定上游，就是master分支，所有分支向上追溯的根源都是master，所以上游和下游是相对的，上游就是从当前分支还新拉了一个分支，那当前分支就是上游，下游就是你从其他分支拉的最新分支。
区别
现在有三个分支，master、merge_test、rebase_test分支来进行演示。
下游分支更新上游分支内容的时候使用 rebase
-
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即可：
上游分支合并下游分支内容的时候使用 merge
这个操作就不需要用rebase了，因为下游全是基于上游开发的，所以上游使用merge即可。
更新当前分支的内容时一定要使用 --rebase 参数
更新当前分支代码时，会有两种方式：
当前分支因为可能会有多个小伙伴同事在提交代码，所以要不定时的更新下当前分支的代码。以前习惯性的喜欢用merge来pull更新代码，也会发现每次pull后，会多出一行提交记录：
Merge remote-tracking branch ‘origin/merge_test‘ into merge_test
因为插入了上面这条提交记录，这样看起来整个分支的提交记录就被打乱了，整个提交记录也就不连贯了，所以建议使用rebase来进行更新当前分支的代码。
使用 rebase 就感觉所有人都在同一条直线上开发一样，历史提交线会很清晰。
还有一个原因：Rebase the currenct branch on top of the incoming changes，把当前分支的基放在即将拉下来的change 的上面。它相当于后移了自己本地分支的检出commit~
以上是结合多个博客总结的
参考原文链接：https://zhuanlan.zhihu.com/p/34197548、
原文：https://www.cnblogs.com/qukun/p/14435309.html