Monorepo 下 Git 工作流的最佳实践 原创

作者：林宜丙

背景

没有哪一种 Git 工作流是银弹，合适的 Git 工作流往往取决于项目的代码规模、协作人数、应用场景等；本次分享先从适合小型 Monorepo 的 Feature branch 工作流开始分享，接着分享适用于中大型 Monorepo 的 Trunk-based 工作流，并给出一些选型标准供同学们参考，希望通过本次分享，大家能找到合适自己 Monorepo 工程的 Git 工作流！

前置知识

我们最熟悉的 Git 工作流莫过于 Git flow, Gilab flow, Github flow，而对于 feature branch 和 trunk-based 比较陌生，那么以上几种 flow 有什么关系呢？

1. Feature branch 和 Trunk-based 工作流是比较新晋的概念，二者是相对的、互斥的，它们组成一个全集；
2. Git flow, Gilab flow, Github flow 都属于 feature branch development，它们有一个共同点：都采用『功能驱动式开发』，即：需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）；

适用场景

在 Monorepo 工程中，使用 feature branch development 开发模式时，随着代码库复杂性和团队规模的增长，并行的『长期分支』也会越来越多，这些分支在合入主干时，将会频繁遇到冲突或者不兼容的情况，而手动解决代码冲突往往会引入 Bug。

而 trunk-based development 鼓励开发者可以通过一些小的提交创建『短期分支』，从而大大缓解冲突问题，有助于保持生产版本的流畅。

总的来说，选择一个工作流不仅仅是一系列操作工具的流程，我们往往还需要对它背后的思想买单；下面的表格是两种工作流模式在各个维度的适用情况：

目前大部分业务场景使用的都是 feature branch 的开发模式，如果你的业务是多人开发一个巨型应用（如抖音主站、飞书文档等），应该尝试使用 Trunk based 开发模式，这会提高仓库整体工程质量和管理水平。