别再推荐Git Flow了

2020 年 3 月 11 日

别再推荐Git Flow了

写在前面

十年前,一篇名为《一个成功的 Git 分支模型》的文章将 Git Flow 推上了风口浪尖。在过去的十年里,无数个开发团队被这篇文章蒙在鼓里。说得严重一点,他们都被骗了。

文章的作者宣称他们已经成功地将 Git Flow 引入到项目中,但对于如何在项目中取得成功的细节却只字未提。

如果我们盲目地相信这篇文章所说的内容,那无疑是一个巨大的错误。我们必须承认,并不是所有的策略都适用于所有的情况、所有的人、所有的环境,而这个道理对于这个分支模型同样适用。

为了更有说服里一点,让我们来更深入地探究一下为什么我们应该让 Git Flow 分支模型葬身火海。

Git Flow 太复杂了

Git Flow 太复杂了,看看下面这张图,它已经很直观地说明了这一点:

这里有功能分支、发布分支、主干、开发分支、紧急修复分支和标签。在构建和发布过程中,你必须跟踪这些东西,还得理解它们,记得它们。

不仅如此,你还需要从头到尾跟踪哪个分支是用来干什么的,这对于你来说是一个很重的认知负担。我已经使用 Git 十年了,我甚至都不确定自己的脑力是否能够承担得了这些东西。

Git Flow 违背了分支的“短命”原则

在使用 Git 时,在同一个分支上开发代码的人越多,出现合并冲突的几率就越高。在使用 Git Flow 后,冲突几率会变得更高,因为还有三个其他的分支(具有不同的生命周期)会合并到开发分支上:功能分支、发布分支和紧急修复分支。现在,出现合并冲突的可能性不是线性的,而是呈三倍的数量增长。

虽然我不愿意说“担心出现合并冲突”是不想采用 Git Flow 分支策略的原因,但当所有这些分支聚集在一起,它们所引入的潜在复杂性是我们无法忽视的。如果你所在的企业提交代码的速度比较慢,或许没什么问题,但对于需要快速开发的企业或初创公司来说,情况就不一样了。

Git Flow 抛弃了 rebase

如果你要使用 Git Flow,就得放弃 rebase。rebase 取消了合并提交——也就是可以看到两个分支合并的地方。由于 Git Flow 的复杂性,你需要可视化跟踪分支,这意味着如果你想要看到来龙去脉,就不能使用 rebase。

Git Flow 阻碍了持续交付

持续交付是指开发团队的每次代码提交都会以自动化的方式(在实际当中是与主干合并)直接发布到生产环境中。看看这一团糟的 Git Flow,你倒是说说如何能够进行持续交付?

Git Flow 分支模型是基于可预测的长期发布周期,而不是基于每隔几分钟或几小时就要发布新代码的场景。这种发布方式的开销太大了。另外,持续交付的一个核心实践是通过修复的方式进行发布,而 Git Flow 将紧急修复作为一个单独的实体,并与其他开发工作分开。

Git Flow 无法应对多代码库

随着微服务的崛起,小型代码库的想法也得到了更多的推动。个体开发团队可以控制他们的代码库和工作流,他们可以控制谁能够向他们的代码库提交代码以及他们的工作流如何工作。

你有没有尝试过使用像 Git Flow 这样的分支模型,并希望每个人都能达成一致?这是不可能的。很快,系统就会出现不同版本的代码库,唯一知道一切的人是使用 YAML 来更新清单的人。你一不小心就很难知道“生产环境中究竟包含了哪些东西”。

Git Flow 无法应对大型单代码库

如果因为版本发布协调困难而无法使用多个微代码库,那为什么不使用一个单独的大型分支工作流,让所有的微服务团队都使用这个工作流?

这种方式在一小段时间内或许是可以的,直到一个开发团队要发布版本而其他团队还没有准备好。如果开发团队是独立的,微服务也是独立部署的,那就不能将你的工作流很好地与这种分支模型结合在一起。

谁应该(或不应该)使用 Git Flow?

如果你所在的公司采用了月度或季度发布周期,并且由一个团队负责并行开发多个项目,那么 Git Flow 可能是一个不错的选择。如果你所在的公司是一个初创公司,或者开发的是一个网站或 Web 应用程序,在一天内可能需要发布多个版本,那么使用 Git Flow 对你来说没有什么好处。如果你的团队规模很小(10 人以下),Git Flow 会给你的带来太多冗繁的工作。

但如果你的团队有 20 多人并行开发多个版本,那么使用 Git Flow 可以确保你们不会把事情搞砸。

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

这个问题我回答不了。并不是所有的分支模型都适用于所有的团队、所有的环境和所有的文化。如果你采用了持续交付,你会想要一些能够尽可能简化交付过程的东西。有些人喜欢基于主干的开发模式,喜欢使用特性标志。然而,从测试的角度来看,这些反而会把我吓一跳。

关键在于你要问你的团队:这种分支模型可以帮助你们解决哪些问题?它会带来哪些问题?这种模式为哪种开发提供更好的支持?你们想要鼓励这种行为吗?你选择的分支模型最终都是为了让人们更容易地进行软件协作开发,因此,分支模型需要考虑到使用者的需求,而不是盲目听信某些人在网上所声称的“成功的分支模型”。

英文原文

Please Stop Recommending Git Flow

2020 年 3 月 11 日 14:21 6521
用户头像
小智 InfoQ高级编辑

发布了 180 篇内容,共 3919 次阅读,收获喜欢 23 次。

关注

评论 4 条评论

发布
用户头像
什么GP文章……
2020 年 03 月 25 日 13:59
回复
用户头像
gitflow 显然不是适合每一个场景的,然而现有的工作流程gitflow也是无可替代的
2020 年 03 月 23 日 09:57
回复
用户头像
这作者既然脑力有限,无法理解 gitflow,就何必还要基于自己错误的理解来进行批判…
2020 年 03 月 16 日 09:58
回复
用户头像
如果没有更好的标准,那就按照 Git Flow 来。文章作者的意思绝对不是要对 Git Flow 生搬硬套,应用到实际项目中可以修改。
2020 年 03 月 15 日 15:04
回复
没有更多评论了
发现更多内容

Linux学习-2020.05.11

蜗牛前进

Java 为什么需要包装类

Rayjun

Java

每个人都应该知道的性能参数

ElvinYang

带你吃透原型设计

Yanel 说敏捷产品

产品 产品经理 产品设计 产品开发 产品推荐

你真的懂"看板文化"么?

Yanel 说敏捷产品

敏捷 敏捷开发 敏捷精髓

接口限流算法有哪些,看完这篇又能和面试官互扯了~

不才陈某

分布式 后端 Java、

NIO 看破也说破(三)—— 不同的IO模型

小眼睛聊技术

Java 深度思考 学习方法 程序员 架构

医院陪护5天的四点感受

赵新龙

身心健康 医院

前端有未来吗?

欧雷

前端 前端开发

如何高效阅读

ElvinYang

目光聚集之处,金钱必将追随

Tom

学习 个人成长 思考 读书

【解析+示例】2种方法,通过SpreadJS在前端实现甘特图

Geek_Willie

前端开发 甘特图 SpreadJS 表格控件

DDD 实践手册(6. Bounded Context - 限界上下文)

Joshua

企业架构 设计模式 领域驱动设计 DDD 架构模式

你的团队属于部落的哪个阶段?

Yanel 说敏捷产品

敏捷 敏捷开发 敏捷精髓

Python程序性能分析和火焰图

ElvinYang

工具集系列|值得收藏的几个免费在线学习国外网站

一尘观世界

学习 工具 网站 在线学习 提升

追光逐影:读《我们这一代》

北风

从技术层面理解对于区块链技术的10.24集体学习讲话

MaxHu

区块链 智能合约 以太坊 加密货币 去中心化网络

对话 CTO | 喜茶也有 CTO?听陈霈霖讲讲茶饮中的技术甜度

ONES 王颖奇

研发管理 CTO 零售

如何让团队产生“多米诺骨牌”效应?

Yanel 说敏捷产品

项目管理 敏捷 敏捷开发 敏捷精髓

也谈程序员的核心竞争力

我心依然

程序员 竞争力 独立思考 清晰表达 持续学习

良好的工作习惯——及时存档、备份

Sicolas Flamel

工作效率

错过了初恋,别错过WebFlux

稻草鸟人

stream Spring5 WebFlux Reactive

Try-Catch包裹的代码异常后,竟然导致了产线事务回滚!

码大叔

Java spring 事务

认识数据产品经理(二 数据产品经理的稀缺性)

马踏飞机747

大数据 互联网 数据分析 数据产品经理

危机过后,「表格文档协同」需要具备什么能力?

Geek_Willie

前端开发 开发者工具 Excel

ShedLock:一个轻量级的定时任务协调组件

SunYk

定时任务 shedlock

ITerm2 + Oh my ZSH + Powerlevel10k

JDoe

配置

Python网络编程socket 简易聊天窗

蜗牛前进

C语言常量、变量和关键字

C语言技术网-码农有道

C语言 常量 变量 关键字

对话 CTO | 听快看漫画 CTO 李润超讲重塑漫画产业的技术推动力

ONES 王颖奇

研发管理 CTO 动画 文化

别再推荐Git Flow了-InfoQ