Git Flow 被抛弃的 8 大理由

Posted linuxprobe0001

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Git Flow 被抛弃的 8 大理由相关的知识,希望对你有一定的参考价值。

导读 Git-flow 是一种分支和合并方法。十年前,因为一篇名为「一个成功的 Git 分支模型」的文章,Git-flow 变得广为人知。

技术图片

在过去的十年里,无数团队被这篇博文蒙在鼓里。但我敢说,这篇文章撒谎了。

如果你读过这篇博文,你就会注意到,尽管作者声称他们在项目中成功使用了 Git-flow ,但却故意避开了让项目成功的细节。

很多人会相信看到的博文,这其实是错误的。并非所有的策略都适用于所有情况,这是一个真理。我将同样的逻辑应用于这个分支模型。

好吧,你们当中的一些人不相信这个真理,所以让我们深入研究为什么 Git-flow 分支模型应该葬身火海。

Git-flow 的界面很复杂

Git-flow 特别复杂,甚至在考虑微服务或连续交付之前就已经如此了。下面的图片直观地展示了这一点:

这里有特性分支、发布分支、master 分支、dev 分支、一个紧急修复分支和 git 标记。这些都是在构建和发布过程中必须跟踪、理解和考虑的事情。

更重要的是,你还需要随时跟踪每个分支,这造成了很高的认知负荷。我已经使用 git 10 年了,我甚至不确定自己是否能在精神上跟上这里的发展。

Git-flow 违反了「短命」分支规则

在 git 中,随着在某个分支上工作人数的增加,发生合并冲突的次数将大大增加。在 Git-flow 中,这个数字增加得更多,因为还有三个具有不同生命周期的其他分支合并到开发中:特性分支、发布分支和紧急修复。合并冲突发生的可能性并不是线性变化的,它可能会使合并冲突的概率增加三倍。

这太糟糕了。

虽然我不敢说不采用 Git-flow 这样的分支策略就可以避免合并冲突,但是当所有这些分支组合在一起时,引入的潜在复杂性太大了,无法忽略。如果你们公司的代码提交速度很慢,那就没关系。但是对于任何快速迭代的组织或初创企业来说,情况并非如此。

Git-flow 放弃了 rebase

重新定位合并节点是一个复杂的话题,但它很重要。如果你使用 Git-flow,你将不得不放弃 rebase。记住,rebase 取消了合并提交,你再也看不到两个分支组合在一起的节点。由于 Git-flow 的视觉复杂性,你需要可视化地跟踪分支,这意味着如果你想解决问题,就不需要 rebase。

Git-flow 使连续交付变得不可能

持续交付是一种实践。在这种实践中,团队以自动化的方式直接发布到生产中(实际上是合并到 master)。看看混乱的 Git-flow,你能解释一下如何持续地交付吗?

整个分支模型是根据可预测的、长期的发布周期进行预测的。如果每隔几分钟或几小时发布一次新代码,开销就太大了,更不用说 CD 的中心实践之一是向前滚动修复。Git-flow 将修补程序视为一个单独的实体,需要小心地控制,并与其他工作分离开来。

在多个存储库中不可能使用 Git-flow

随着微服务的出现,micro-repo 的理念也得到了更多的推动,各个团队可以控制他们的存储库和工作流,他们还可以控制谁进入了他们的存储库以及其工作流是如何工作的。

你有没有尝试过这样一个复杂的分支模型:它有多个团队,并且希望它们都在同一个页面上?这是不会发生的。很快,这个系统就变成了不同 repo 的不同版本的一个清单,只有敲出 YAML 来更新清单的人知道所有东西在哪里。如果你不够细心,「在生产什么」就变成了一个存在主义的问题。

Git-flow 也不可能在 monorep 中使用

因此,如果由于协调发布的困难而取消了 micro-repo,那为什么不让所有微服务团队都遵守一个大的发布分支工作流呢?

这个过程大约持续 3.2 秒。如果团队是独立的,micro-repo 应该是独立部署的,这样就不能很好地将你的工作流程与你在 mono repo 中创建的集中式分支模型联系起来。

谁应该/不应该使用 Git-flow?

如果你的团队每月或每季度发布一次,并且是一个并行处理多个发布的团队,那么 Git-flow 可能是一个不错的选择。如果你的团队是一个初创企业,或者是一个面向 internet 的网站或 web 应用程序,同一天可能发布多个版本,那 Git-flow 对你来说就不合适了。如果你的团队是一个不到 10 人的微型团队,Git-flow 会给你的工作带来太多的规矩和开销。

另一方面,如果你的团队有 20 多人进行并行发布,那么 Gitflow 可以确保不会把事情搞砸。

如果不应该使用 Git-flow,那应该用什么?

我不能回答。并非所有分支模型都适用于所有团队和所有情况。如果你练习 CD,你需要一些尽可能简化过程的东西。

关键在于,团队需要反思:这个分支模型将帮助我们解决哪些问题?会产生什么问题?这种模型将鼓励什么样的发展?我们想鼓励这种行为吗?使用分支模型的最终目的都是方便软件开发过程中的合作,因此,需要考虑使用它的特定人群的需求,而不是互联网流传的「成功」的东西。更多Linux资讯请查看:https://www.linuxprobe.com

以上是关于Git Flow 被抛弃的 8 大理由的主要内容,如果未能解决你的问题,请参考以下文章

Web前端技术分享:学习HTML和CSS的5大理由

为什么要选择学Web前端?无法反驳的4大理由

大波新特性到来,升级到 Ubuntu 18.04 LTS 的 8 大理由

我放弃Python转Go语言的9大理由(附优秀书籍推荐)

前端开发程序员选择Vue.js的5大理由

三个知识点搞定git-flow