作为一名程序员，经常和 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 分支。开发者分支即可删除，一项开发工作完成。

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

Git Flow 同样可以用于发布（release）产品。

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

对于稳定版本（Stable），则需要一些其他技巧。

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

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

按照正常的发布流程，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🔗