什么是 Git Flow
2024-07-31
作为一名程序员,经常和 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 需要做三件事:
- 冲突检查。如果相同位置,main 分支上已经合入了别人的修改,那提交 pull request 的开发者有义务解决冲突。
- Pipeline check。比如编译检查,单元测试,集成测试等。
- 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。
直观,清晰,可预测,固定的输入,必然带来固定的输出。
可惜,我们的人生,并不会像代码运行那样充满了确定。我的一个朋友说:保持泛化,同样是一种能力。
(完)
参考
- 本文作者:Plantree
- 本文链接:https://plantree.me/blog/2024/git-flow/
- 版权声明:所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明出处!
最后更新于: 2024-08-01T06:32:25+08:00