什么是 Git Flow

2024-07-31 pv

作为一名程序员,经常和 Git 打交道。

Git 是目前最主流的版本控制工具,不仅对于个人开发很重要,对于团队协作也是如此。

今天这篇文章,不会具体介绍如何使用 Git,网上这方面的教程很多。这里打算讨论下 Git Flow,它是什么,用来解决什么问题,以及怎么解决的。

1. Git Flow 含义

简单来说,Git 管理的是代码,Git Flow 管理的,是从代码到产品交付的过程。

关于一个产品如何发布,可以参考之前的文章:如何发布一个客户端🔗

那篇文章提到的解决方案,就可理解为是一种 Git Flow。

这篇文章将展开讲讲。

无论对于个人开发,还是团队开发,一个清晰、完备的 Git Flow 都是必要的,这就像是一个 SOP (Standard operating procedure, 标准作业流程),不仅能提高开发效率,而且有助于稳健地发布产品。

不同团队有不同的方案,比如 Github Flow🔗Gitlab Flow🔗。有差异,但核心思想一致。

2. 常见用法

实际开发中,冲突(conflict)普遍存在。

不同功能之间会冲突,现在和过去会冲突,不同成员之间也会冲突。

Git Flow 使用分支(branch)管理冲突。

Git 仓库有一个 main 分支,后续所有的开发都基于它。

如果团队中某个成员想要开发一个新功能,或者 bug-fix,比如张三,就要切一个分支出来:user/zhangsan/feature

所有的开发和测试工作都在本地完成。因此张三的工作对其他成员来说并不可见,自然也就不会引起冲突:大家各做各的,互不影响。

当开发完成,就需要合入 main 分支,于是张三提交了一个 pull request。

通常 pull request 需要做三件事:

  1. 冲突检查。如果相同位置,main 分支上已经合入了别人的修改,那提交 pull request 的开发者有义务解决冲突。
  2. Pipeline check。比如编译检查,单元测试,集成测试等。
  3. Code review。一旦开发者分支合入 main 分支,后续其他人就能看到修改,因此需要严格的代码审查机制,通常由更高阶、更熟悉代码的开发者负责。

三项条件满足后,开发者分支合入 main 分支。开发者分支即可删除,一项开发工作完成。

Loading graph...

main 分支上包含了最新的 feature 和 bug-fix。对一个厨师而言,当所有的食材准备完毕,下一步就该考虑如何烹制了。

Git Flow 同样可以用于发布(release)产品。

对于金丝雀版本(Canary),只需要在 main 分支上定期打 tag,基于 tag 对应的 commit id,编译产出,发布。

对于稳定版本(Stable),则需要一些其他技巧。

稳定版本是滞后于 main 分支的。这提供了灰度地带。只有那些在金丝雀版本上验证没有问题的功能,才会真正出现在稳定版本中。

稳定版本的发布,同样使用分支。根据发布节奏,从 main 分支上切出一条 stable [version] 分支,切分支的点,通常是历史上的某个时间,比如两周前。

Loading graph...

按照正常的发布流程,main 分支上最新的修改,不会出现在当前 stable 版本中。但有例外。

比如,出现了某个重大的 bug,导致 stable 版本大范围崩溃,就需要紧急修复。此时可以将 bug-fix,从 main 分支 cherry-pick 到 stable 分支。

这是一个需要谨慎操作的行为

因为如果验证不完备,会将新的问题引入到 stable 版本中,接下来就需要不断地打补丁。这样会打乱正常的发布节奏。

3. 背后哲学

按照我的理解,Git Flow 其实是制定了一系列规范。规范化带来的好处是清晰,确定性强。

对于,怎么创建分支,如何 code review,代码 check-in,发布的时间点选择,问题如何快速修复,都有明确的指导和约束。

越是自由的地方,就越是需要约束。

为什么脚本语言容易写,但不容易维护?

为什么会衍生出 TypeScript 这种强类型约束的语言?

古话说:没有规矩,不成方圆

如果一个开发者,随意地在 main 分支上修改,看心情选择发布新产品,系统很快便会因为熵的迅速增加而陷入无序。

对于一个软件系统,代码腐烂(Software rot)是一件必然发生,且不可逆的过程。

像我现在开发的产品,基于 Chromium,一个尽管在业界饱受好评的开源项目。如果你真正打开,会发现,里面同样充斥着各种冗余,无意义的调用。

Git Flow,或者说 Flow,是尝试通过建立一种秩序,对冲日复一日的,系统逐渐走向混沌的倾向

4. 总结

现在越来越喜欢 Flow 的思想。

我老婆平时喜欢喝的一个酸奶品牌,叫茉酸奶。我仔细观察过,其实也不止茉酸奶,其他奶茶品牌也都有,一套 SOP。做好奶茶,先擦拭一遍杯体,如果现场喝,店员会拆开吸管,用拆开的纸横起来,顶住吸管,压入杯子,避免手的接触。

这应该是程序员很喜欢的流程,充满了 if...else.. 的判断。

因为程序本身,就是一个巨大的 Flow。

直观,清晰,可预测,固定的输入,必然带来固定的输出。

可惜,我们的人生,并不会像代码运行那样充满了确定。我的一个朋友说:保持泛化,同样是一种能力。

(完)

参考

  1. 阮一峰的网络日志-Git 工作流程🔗
  2. Github Docs-GitHub flow🔗
在 GitHub 上编辑本页面

最后更新于: 2024-08-01T06:32:25+08:00