技术编程|字节研发设施下的 Git 工作流


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

技术编程|字节研发设施下的 Git 工作流
本文插图

图片来源:https://nvie.com/posts/a-successful-git-branching-model/
初级 Git 开发者 , 面对这满图的分支和 merge 指向 , 简直想手撕作者 。 高级 Git 开发者要将这个流程运用实践也大感头疼 。
Git Flow 有不少优点:
? 分支各司其职 , 覆盖大部分开发场景 。
? 预期 master 分支中任何 commit 都是可部署的 。
? 严格按照流程执行 , 出现重大事故的情形会大大降低 。
缺点也不少:
? 过于繁琐 , 无法要求所有团队成员按照这个流程严格执行 。
? 违反 git 提倡的 short-lived 分支原则 。
? master 分支历史记录并不干净 , 只能通过打 Tag 标记哪些是 master 真正要部署的 。
? 对持续部署和 monorepo 仓库不友好 。 GitHub Flow
GitHub Flow 是一个基于分支的轻量级工作流 。 它突出了 CR 的重要性 , 有助于我们掌握 CR 的开发模式 , 但它没有解答部署、环境、发布、集成等问题 。

技术编程|字节研发设施下的 Git 工作流
本文插图

图片来源:https://guides.github.com/introduction/flow/index.htmlGitLab Flow
GitLab Flow 并不像 Git Flow, GitHub Flow 一样具有明显的规范 , 它更多是在 GitHub Flow 基础上 , 综合考虑环境部署、项目管理等问题而得出的一种实践 。 基于环境:

技术编程|字节研发设施下的 Git 工作流
本文插图


技术编程|字节研发设施下的 Git 工作流
本文插图

图片来源:https://docs.gitlab.com/ee/topics/gitlab_flow.html基于发布计划:

技术编程|字节研发设施下的 Git 工作流
本文插图

【技术编程|字节研发设施下的 Git 工作流】图片来源:https://docs.gitlab.com/ee/topics/gitlab_flow.htmlTrunk-based Flow
和“基于发布计划”的 GitLab Flow 类似 , 有一个主干分支接受所有开发者的 commit , 并为后续 CI/CD 提供关键助力 。
按照官方文档描述:「你可以选择直接向主干分支提交代码的方式(适用于小团队)或者采用 Pull-Request 的方式 , 只要保证特性分支不能长期存在 , 并且产品是独立存在的 。 (the product of a single person.)」 , trunk 分支提交是比较随意的(不一定可部署) , 但也需要走 CR , 可以采用 Fast-forward 形式的 merge 保证主干是一条线 , 到了合适的时间点 , checkout release-* 分支 , 执行正式上线操作 。


推荐阅读