写点什么

别再推荐 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:217110
用户头像
小智 前 InfoQ 主编

发布了 399 篇内容, 共 312.0 次阅读, 收获喜欢 1736 次。

关注

评论 6 条评论

发布
用户头像
GP不通. 吃饭还会噎死呢. 干脆不吃饭吧
2020 年 11 月 05 日 14:27
回复
用户头像
如果你只是单纯反对一个东西而不提出替代方案,那你的反对毫无意义
2020 年 10 月 13 日 15:44
回复
用户头像
什么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
回复
没有更多了
发现更多内容

架构师训练营 大作业(一)

陆不得

超详细超级细B站视频爬取

海绵宝宝re儿

python 爬虫 多进程

解构 Dubbo-go 的核心注册引擎 Nacos

apache/dubbo-go

dubbogo

区块链如何使金融服务更安全更公平

CECBC区块链专委会

区块链 金融

架构师训练营第 1 期 -- 第一周学习总结

发酵的死神

极客大学架构师训练营

架构师训练营 大作业(二)

陆不得

一个敏捷教练成长必备的8项技能

华为云开发者社区

程序员 敏捷 敏捷开发 敏捷教练 技术技能树

你有没有想过为什么交易和退款要拆开不同的表?

程序员小航

设计 开发 交易 拆表

第一周总结

黄立

架构师 架构总结

我把Github上最牛b的Java教程和实战项目整合成了一个PDF文档

Java成神之路

Java 编程 程序员 项目实战

第一周学习心得

alpha

极客大学架构师训练营

2020年最新最全BAT499道Java面试题(附答案):JVM+分布式+算法+锁+MQ+微服务+数据库【完美搞定金九银十】

云流

编程 程序员 架构师 计算机 java面试

test

leesofte

test

架构师训练营第一周--UML图练习&学习总结

我是谁

极客大学架构师训练营

iOS面试梳理 - 2020年8月初

iOSer

ios 面试 面试题

小码农也有大目标,最新BAT大厂Java面试总结

Java架构师迁哥

开发者说:愿为你点亮“懂环境知冷暖”智能的灯

华为云开发者社区

人工智能 物联网 NB-IoT 路灯 华为IoT平台

GitHub上标星75k+的《Java面试突击版》到底有多牛?看完内容我服了!

Java成神之路

Java 编程 程序员 面试

架构师0期大作业2

Nan Jiang

Spring-技术专题-重试机制Retry机制

李浩宇/Alex

在审计工作中如何运用区块链技术

CECBC区块链专委会

区块链 金融 审计

架构师0期大作业1

Nan Jiang

防止重复点击2.0

老菜鸟

Vue

大作业

大作业

Geek_196d0f

食堂就餐卡系统设计

发酵的死神

极客大学架构师训练营

我在项目内使用了设计模式后,同事直呼看不懂

云流

学习 编程 程序员 架构师

10大高性能开发宝石

李浩宇/Alex

极客大学架构师训练营 0 期 结课作业

chun1123

架构师 架构师技能

食堂就餐卡系统设计

Gosling

极客大学架构师训练营

9省市新基建规划比较:区块链成标配,多地提及数字资产交易

CECBC区块链专委会

区块链 数字资产 新基建

OCR技术的未来发展与演进

OCR技术的未来发展与演进

别再推荐Git Flow了-InfoQ