码迷,mamicode.com
首页 > 其他好文 > 详细

Git Flow 被抛弃的 8 大理由

时间:2020-04-04 14:54:09      阅读:93      评论:0      收藏:0      [点我收藏+]

标签:规则   资讯   解决问题   线性   并行处理   而不是   应该   数字   必须   

导读 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 大理由

标签:规则   资讯   解决问题   线性   并行处理   而不是   应该   数字   必须   

原文地址:https://www.cnblogs.com/linuxprobe0001/p/12631444.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!