乐趣区

关于git:你在开发过程中使用Git-Rebase还是Git-Merge

摘要: 在 git 外面常常的一个争执是到底用 rebase 还是用 merge?

  1. 苦楚吗?代码历史中的迷失羔羊

咱们先来看一个实在的代码提交历史图形化截图:

图片源自 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 造成的。

而相似这样电路板状的代码提交历史是没有意义的,因为太过简单了。简直没有可读性。如果你想去查看某些历史记录的时候,很容易被迅速吞没在这些信息陆地外面无法自拔,最初失去自我,迷失了。

  1. 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 时请确保晓得你在做什么。

  1. 一杯水与一桶水

先说一下一杯水和一桶水的关系,这个关系能够用来形容老师向学生传授常识的情景。次要意思是说老师要是给学生一杯水的话,这个老师必须要有一桶水才行。

其实对于咱们软件行业来说,这个情理也是实用的。

对于本文的聚焦点代码历史,咱们想给内部出现的是清晰洁净的代码历史记录。要到的这个指标,咱们须要做很多的工作,这项工作相较于洁净的代码历史就是一桶水与一杯水的关系。

这也是咱们常常说的,对本人狠一点,让他人难受一点。对本人狠一点不是一句空话,实际上是让本人搜索枯肠的去想,如何把这个事件做好?把本人放在对方的角度下来看咱们的输入后果。咱们问本人,我作为这些代码的维护者和接收者,是不是能够承受这样凌乱的代码历史记录,答案当然是否定的。

明确了这一点,在咱们做代码历史治理的时候,再苦再累也是值得的。

一些有多年工作教训的程序员,他们可能用过很多代码治理的工具,这些代码管理工具在应用的时候常常用的一个操作就是 merge。进入到 git 时代当前,这些程序员也保留了这样的习惯,间接就 merge。

我跟一些程序员聊过,他们甚至都没有意识到有 rebase 这个操作。有的则感觉 rebase 太麻烦了,用了几次就放弃了。

这相对是人情世故。

当咱们习惯了用一种形式做事的时候,咱们做得越久感觉越平安,因为它是卓有成效的,可能解决问题的。当有另外一种更好的形式,然而却与以前的形式有很大差别的时候,咱们就会有本能的排挤心理。这是源于咱们对未知领域的一种恐惧感。

来到舒服区当前,咱们大多数人都会有一种不适应,有的甚至会产生很强烈的失落感。

然而当咱们回归本心的时候,咱们会发现咱们所付出的所有,禁受的苦楚都是值得的。因为咱们的初心就是让用户称心。代码历史的用户就是咱们这些程序员。

  1. 如何正确做 rebase?

要点备注:

Rebase 相干的要点有这几个:

  1. 在本人的分支上做 Rebase;
  2. 要 Rebase 正确的指标分支,留神这个指标分支不是你的近程分支,这个中央常常有人犯错;
  3. Rebase 要常做,以避免出现抵触,或者抵触的难度减少;
  4. 在合入代码之前,肯定要最初做一次 Rebase 再 Merge;
  5. 最好用 Squash Merge, 增加正确的提交音讯;
  6. 不要在主分支上做 Rebase;
  7. 尽量不要 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…

点击关注,第一工夫理解华为云陈腐技术~

退出移动版