共计 3578 个字符，预计需要花费 9 分钟才能阅读完成。
摘要： 在 git 外面常常的一个争执是到底用 rebase 还是用 merge?
- 苦楚吗？代码历史中的迷失羔羊
咱们先来看一个实在的代码提交历史图形化截图：
图片源自 https://storage.kraken.io/kk8…
https://dev.to/neshaz/git-mer…
不晓得大家看到这张图当前有什么感触？是不是很无语呢？我是无语凝噎的感触。代码历史到了这个境地，基本上是废了的！！！
通过本文咱们就来谈一下代码历史线的问题。这里波及到一个代码历史的治理问题，如果你心愿领有比拟清晰的代码历史，从而能够很疾速地追溯你以前的代码记录的话，你肯定要关注这个话题。
如果你作为一个程序员用过 mercurial，你可能对这个 rebase 概念曾经有所理解。目前程序员用的最多的 source control 工具是 git。在 git 外面常常的一个争执是到底用 rebase 还是用 merge?
说争执实际上是不太精确的。因为在理论工作中，这次要有两种状况，一是基本就不晓得 rebase，另外一种是基本就不晓得怎么用 rebase。
那咱们就说一下 rebase 和 merge 的区别，在性能上 rebase 把你以后的批改工作晋升到最前沿,
你本人独有的批改记录程序不会扭转，然而工夫次要会基于以后指标分支的工夫戳进行调整。
Merge 不会扭转工夫戳。这样就会导致不同的人在合并本人批改代码记录的时候，会呈现互相交织的情景。本文开篇是一张代码提交历史的截屏，外面的连线就像电路板一样简单。
呈现这样的状况，次要是因为程序员不做 rebase 间接 merge 造成的。
而相似这样电路板状的代码提交历史是没有意义的，因为太过简单了。简直没有可读性。如果你想去查看某些历史记录的时候，很容易被迅速吞没在这些信息陆地外面无法自拔，最初失去自我，迷失了。
- Git Merge vs. Rebase
小注：尽管曾经参考链接中标注，然而有必要再强调一下此节翻译参考了如下链接的英文内容：
https://dev.to/neshaz/git-mer…
Git merge 和 rebase 的目标是一样的，它们都是将多个分支合并成一个。尽管他们最终的指标是一样的，但这两种办法实现的形式是不同的。那么咱们应该用哪个呢？
这里咱们有一个示例仓库，它有两个不同的分支：主分支和个性分支。咱们想把它们交融在一起。让咱们来看看如何应用这些办法来解决这个问题。
图片源自 https://storage.kraken.io/kk8…
https://dev.to/neshaz/git-mer…
Merge
当你运行 git merge 时，你的 HEAD 分支会生成一个新的提交，并保留每个提交历史的先人。
图片源自 https://storage.kraken.io/kk8…
https://dev.to/neshaz/git-mer…
Fast forward merge 是一种不创立提交的合并类型，会更新分支指针到上一次提交。
Rebase
Rebase 是将一个分支的批改重写到另一个分支上，而不须要创立新的提交。
你在个性分支上的每一个提交，都会在主分支上创立一个新的提交。这看起来就像这些提交始终是写在主分支之上的一样。
图片源自 https://storage.kraken.io/kk8…
https://dev.to/neshaz/git-mer…
Merge 的长处和毛病
长处
- 应用简略，易于了解。
- 放弃源分支的原始上下文。
- 源分支上的提交与其余分支的提交是离开的。
- 能够保留提交历史。
毛病
- 乱
图片源自 https://storage.kraken.io/kk8…
https://dev.to/neshaz/git-mer…
Rebase 的长处和毛病
长处
- 代码历史是简化的、线性的、可读的。
- 与许多独立的个性分支的提交历史相比，操作单个提交历史更容易。
- 洁净、清晰的提交信息能够更好地跟踪一个 bug 或何时引入的某个性能。能够防止泛滥的单行提交净化历史。
毛病
- 会更改历史提交工夫，可能会失落上下文。
比起 Merge，你须要更加小心的应用 Rebase。
应该用 Merge 还是 Rebase?
当你的团队对于 rebase 不相熟时，那么 git merge 就是你的正确抉择。
- Merge 容许保留任何给定性能的提交历史，而不用放心笼罩提交和扭转历史。
- 它能够防止不必要的 git revert 或 reset。
另一方面，如果你更看重洁净、线性的代码历史，那么 git rebase 是最合适的。这种形式能够防止不必要的提交，并放弃更集中和线性的变动!
这里要留神的是，如果你不正确地重写了历史，可能会导致重大的问题，所以在应用 Rebase 时请确保晓得你在做什么。
- 一杯水与一桶水
先说一下一杯水和一桶水的关系，这个关系能够用来形容老师向学生传授常识的情景。次要意思是说老师要是给学生一杯水的话，这个老师必须要有一桶水才行。
其实对于咱们软件行业来说，这个情理也是实用的。
对于本文的聚焦点代码历史，咱们想给内部出现的是清晰洁净的代码历史记录。要到的这个指标，咱们须要做很多的工作，这项工作相较于洁净的代码历史就是一桶水与一杯水的关系。
这也是咱们常常说的，对本人狠一点，让他人难受一点。对本人狠一点不是一句空话，实际上是让本人搜索枯肠的去想，如何把这个事件做好？把本人放在对方的角度下来看咱们的输入后果。咱们问本人，我作为这些代码的维护者和接收者，是不是能够承受这样凌乱的代码历史记录，答案当然是否定的。
明确了这一点，在咱们做代码历史治理的时候，再苦再累也是值得的。
一些有多年工作教训的程序员，他们可能用过很多代码治理的工具，这些代码管理工具在应用的时候常常用的一个操作就是 merge。进入到 git 时代当前，这些程序员也保留了这样的习惯，间接就 merge。
我跟一些程序员聊过，他们甚至都没有意识到有 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 把数次提交打包合成一个到主分支上。
以上是我对在失常工作流程中如何应用 rebase 进行了一个事实案例的形容解说, 心愿大家去体验一下，通知我领会，请留言说说你的想法。
参考文献
https://dev.to/neshaz/git-mer…
https://www.perforce.com/blog…
https://product.hubspot.com/b…
https://git-scm.com/docs/gitt…
点击关注，第一工夫理解华为云陈腐技术~
