摘要: 在 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…
点击关注,第一工夫理解华为云陈腐技术~