Git 提供了丰富的分支策略和工作流方式，我们在深入学习业界 Git 工作流时，每种工作流都设计的非常好，似乎都能运用到团队实践。但在引入 Git 工作流规范开发时要留意：Git 工作流仅仅是整个研发流程中的一环。上游项目管理/缺陷追踪系统虎视眈眈，下游 CD (Continuous Delivery) 嗷嗷待哺，还得考虑团队规模、产品形态、发版方式等等因素。因此，在团队中落地 Git 工作流规范并不是一件能轻松决定的事。
字节跳动 Git 仓库有效的 CR (Code Review) 覆盖率 70%，仍有提升空间，通过调研，团队中又以 GitHub Flow 模式居多。随着字节研发效能建设愈发完善，GitHub Flow 已无法充分利用研发设施进行提效并保障工程质量，很多团队均意识到这点并着手建设流程规范。
本文通过介绍业界 Git 工作流和公司研发设施现状，力求从仓库形态、部署流程等多角度进行分析，给出一些制定工作流规范的建议。

业界 Git 工作流介绍

Git Flow

初级 Git 开发者，面对这满图的分支和 merge 指向，简直想手撕作者。高级 Git 开发者要将这个流程运用实践也大感头疼。

Git Flow 有不少优点：

• 分支各司其职，覆盖大部分开发场景。
• 预期 master 分支中任何 commit 都是可部署的。
• 严格按照流程执行，出现重大事故的情形会大大降低。

缺点也不少：

• 过于繁琐，无法要求所有团队成员按照这个流程严格执行。
• 违反 git 提倡的 short-lived 分支原则。
• master 分支历史记录并不干净，只能通过打 Tag 标记哪些是 master 真正要部署的。
• 对持续部署和 monorepo 仓库不友好。

GitHub Flow

GitHub Flow 是一个基于分支的轻量级工作流。它突出了 CR 的重要性，有助于我们掌握 CR 的开发模式，但它没有解答部署、环境、发布、集成等问题。