Git Merge vs Git Rebase
Git merge 和rebase的目的是一样的，它们都是将多个分支合并成一个。虽然他们最终的目标是一样的，但这两种方法实现的方式是不同的。那么我们应该用哪个呢？
这里我们有一个示例仓库，它有两个不同的分支：主分支和特性分支。我们想把它们融合在一起。让我们来看看如何使用这些方法来解决这个问题。
Merge
当你运行 git merge 时，你的 HEAD 分支会生成一个新的提交，并保留每个提交历史的祖先。
Fast forward merge是一种不创建提交的合并类型，会更新分支指针到上一次提交。
Rebase
Rebase是将一个分支的修改重写到另一个分支上，而不需要创建新的提交。
你在特性分支上的每一个提交，都会在主分支上创建一个新的提交。这看起来就像这些提交一直是写在主分支之上的一样。
Merge的优点和缺点
优点
- 使用简单，易于理解。
- 保持源分支的原始上下文。
- 源分支上的提交与其他分支的提交是分开的。
- 可以保留提交历史。
缺点
- 由于许多人并行地在同一分支上工作，因此历史可能会被大量合并提交严重污染。您的存储库的可视化图表可能会变得一团糟，并且不会添加太多信息。它看起来像是伦敦地铁图提交！
- 由于合并提交，使用git bisect进行调试会变得更加困难。
Rebase的优点和缺点
优点
- 代码历史是简化的、线性的、可读的。
- 与许多独立的特性分支的提交历史相比，操作单个提交历史更容易。
- 干净、清晰的提交信息可以更好地跟踪一个bug或何时引入的某个功能。可以避免众多的单行提交污染历史。
缺点
- 会更改历史提交时间，可能会丢失上下文。
比起Merge，你需要更加小心的使用Rebase。
应该用Merge还是Rebase?
当你的团队对于rebase不熟悉时，那么git merge就是你的正确选择。
- Merge允许保存任何给定功能的提交历史，而不必担心覆盖提交和改变历史。
- 它可以避免不必要的 git revert或reset。
另一方面，如果你更看重干净、线性的代码历史，那么git rebase是最合适的。这种方式可以避免不必要的提交，并保持更集中和线性的变化!
这里要注意的是，如果你不正确地重写了历史，可能会导致严重的问题，所以在使用Rebase时请确保知道你在做什么。
如何正确做rebase？
要点备注：
Rebase相关的要点有这几个：
- 在自己的分支上做Rebase;
- 要Rebase正确的目标分支，注意这个目标分支不是你的远程分支，这个地方经常有人犯错；
- Rebase要常做，以避免出现冲突，或者冲突的难度增加；
- 在合入代码之前，一定要最后做一次Rebase再Merge；
- 最好用Squash Merge, 添加正确的提交消息；
- 不要在主分支上做Rebase;
- 尽量不要force push;
在主分支上应该rebase吗? 怎么去做rebase?
首先,我要强调一下，在主分支上不要做rebase。这是因为如果你在主分支上做了rebase，如果你是第1次push可能没有问题，但是如果别的人也做了一个rebase，这个时候就导致你的主分支上有两个不同的head，这个时候如果想再push的话就存在问题了。
如果一切可控的话，你可以非常粗暴的使用强制push。但是如果团队成员比较多，会导致这样的操作会冲掉其他已经进来的提交。
除非万不得已，我们坚决不能在主分支上去做rebase。
接下来说一个正确使用rebase的场景。在接到一个任务以后，我们会在主分支上最新的节点处提交上创建一个新的分支。在新的分支上，我们会不断的进行新的提交，直到完成这个分支任务。
到这个时候，我们想创建一个merge request或者pull request，在此之前，我们首先要做的就是rebase，rebase选的目标分支是我们的主分支。
完成这次rebase操作以后，我们就可以创建mr或者pr了。在审查过程中可能有很多修改意见，修改完成以后需要先
rebase再push。如此反复几次，mr或者pr审批通过。此时要做一次squash merge把数次提交打包合成一个到主分支上。
参考文献
https://xie.infoq.cn/article/27b42db8899970f5e9200a257
https://dev.to/neshaz/git-merge-vs-git-rebase-5134
https://www.perforce.com/blog/vcs/git-rebase-vs-merge-which-better
https://product.hubspot.com/blog/git-and-github-tutorial-for-beginners
