摘要：在git里面经常的一个争论是到底用rebase还是用merge? 1. 痛苦吗？代码历史中的迷失羔羊
我们先来看一个真实的代码提交历史图形化截图：
图片源自 https://storage.kraken.io/kk8yWPxzXVfBD3654oMN/c8b97f4dbb5f7d49fc3eb3624eafff79/london-tube-map-commit.png
https://dev.to/neshaz/git-merge-vs-git-rebase-5134
不知道大家看到这张图以后有什么感受？是不是很无语呢？我是无语凝噎的感受。代码历史到了这个地步，基本上是废了的！！！
通过本文我们就来谈一下代码历史线的问题。这里涉及到一个代码历史的管理问题，如果你希望拥有比较清晰的代码历史，从而可以很快速地追溯你以前的代码记录的话，你一定要关注这个话题。
如果你作为一个程序员用过mercurial，你可能对这个rebase概念已经有所了解。目前程序员用的最多的source control工具是git。在git里面经常的一个争论是到底用rebase还是用merge?
说争论实际上是不太准确的。因为在实际工作中，这主要有两种情况，一是根本就不知道rebase，另外一种是根本就不知道怎么用rebase。
那我们就说一下rebase和merge的区别，在功能上rebase把你当前的修改工作提升到最前沿,
你自己独有的修改记录顺序不会改变，但是时间主要会基于当前目标分支的时间戳进行调整。
Merge不会改变时间戳。这样就会导致不同的人在合并自己修改代码记录的时候，会出现相互交错的情形。本文开篇是一张代码提交历史的截屏，里面的连线就像电路板一样复杂。
出现这样的情况，主要是因为程序员不做rebase直接merge造成的。
而类似这样电路板状的代码提交历史是没有意义的，因为太过复杂了。几乎没有可读性。如果你想去查看某些历史记录的时候，很容易被迅速淹没在这些信息海洋里面无法自拔，最后失去自我，迷失了。
2. Git Merge vs. Rebase小注：虽然已经参考链接中标注，但是有必要再强调一下此节翻译参考了如下链接的英文内容：
https://dev.to/neshaz/git-merge-vs-git-rebase-5134
Git merge 和rebase的目的是一样的，它们都是将多个分支合并成一个。虽然他们最终的目标是一样的，但这两种方法实现的方式是不同的。那么我们应该用哪个呢？
这里我们有一个示例仓库，它有两个不同的分支：主分支和特性分支。我们想把它们融合在一起。让我们来看看如何使用这些方法来解决这个问题。
图片源自 https://storage.kraken.io/kk8yWPxzXVfBD3654oMN/fc73a41ce658a6a566e2a54d60534ade/git-flow.png
https://dev.to/neshaz/git-merge-vs-git-rebase-5134
Merge当你运行 git merge 时，你的 HEAD 分支会生成一个新的提交，并保留每个提交历史的祖先。
图片源自 https://storage.kraken.io/kk8yWPxzXVfBD3654oMN/673b91456bdc6fd454c5ad203f825568/git-merge-2.png
https://dev.to/neshaz/git-merge-vs-git-rebase-5134
Fast forward merge是一种不创建提交的合并类型，会更新分支指针到上一次提交。
Rebase是将一个分支的修改重写到另一个分支上，而不需要创建新的提交。
你在特性分支上的每一个提交，都会在主分支上创建一个新的提交。这看起来就像这些提交一直是写在主分支之上的一样。
图片源自 https://storage.kraken.io/kk8yWPxzXVfBD3654oMN/5ade4f7276bc6ad18dad4b6078950ac9/git-rebase.png
https://dev.to/neshaz/git-merge-vs-git-rebase-5134
Merge的优点和缺点 优点使用简单，易于理解。
保持源分支的原始上下文。
源分支上的提交与其他分支的提交是分开的。
可以保留提交历史。
缺点乱
图片源自 https://storage.kraken.io/kk8yWPxzXVfBD3654oMN/c8b97f4dbb5f7d49fc3eb3624eafff79/london-tube-map-commit.png
https://dev.to/neshaz/git-merge-vs-git-rebase-5134
Rebase的优点和缺点 优点
代码历史是简化的、线性的、可读的。
与许多独立的特性分支的提交历史相比，操作单个提交历史更容易。
干净、清晰的提交信息可以更好地跟踪一个bug或何时引入的某个功能。可以避免众多的单行提交污染历史。
缺点会更改历史提交时间，可能会丢失上下文。
比起Merge，你需要更加小心的使用Rebase。
应该用Merge还是Rebase?当你的团队对于rebase不熟悉时，那么git merge就是你的正确选择。
Merge允许保存任何给定功能的提交历史，而不必担心覆盖提交和改变历史。
它可以避免不必要的 git revert或reset。
另一方面，如果你更看重干净、线性的代码历史，那么git rebase是最合适的。这种方式可以避免不必要的提交，并保持更集中和线性的变化!
这里要注意的是，如果你不正确地重写了历史，可能会导致严重的问题，所以在使用Rebase时请确保知道你在做什么。
3. 一杯水与一桶水