Web 开发的单体仓库策略

单体仓库：在单个仓库中管理多个项目

单体仓库是一个包含多个项目的单一 Git 仓库。无需为前端、后端、共享库和文档分别设置仓库，而是将它们全部放在一个地方。这种方法由 Google、Meta 和 Microsoft 率先采用，现在在各种规模的团队中都很流行。

为什么使用单体仓库

主要优势是代码共享。当前端和后端共享 TypeScript 类型时，可以一次定义，随处使用。共享工具函数、验证模式和配置文件都放在一个地方。影响多个项目的更改可以在一次提交中完成，而无需在多个仓库之间协调。

原子提交是另一个好处。当更改 API 端点并需要更新前端以匹配时，可以在一次提交中完成。没有时间问题，没有版本不匹配。代码审查显示更改的全貌。跨项目边界的重构也很简单。

工具

有几种工具使单体仓库变得实用。Nx 是一个强大的构建系统，具有智能缓存、依赖关系图感知和对许多框架的支持。Turborepo 更简单，专注于缓存和任务编排。pnpm 工作区和 Yarn 工作区通过包链接提供基本的单体仓库支持。

这些工具了解哪些项目依赖于哪些项目，并且可以只运行受更改影响的测试和构建。这使得单体仓库即使在规模变大时也能保持快速。

组织单体仓库

典型的单体仓库结构将共享代码放在 packages 目录中，应用程序放在 apps 目录中，工具配置放在根目录。每个包都有自己的 package.json、TypeScript 配置和测试。根配置为 linting、格式化和测试设置共享标准。

明确的所有权很重要。虽然代码位于一个仓库中，但不同的团队可以拥有不同的包。CODEOWNERS 文件定义了谁负责什么。CI 管道可以根据更改的文件配置为运行不同的检查。

潜在挑战

单体仓库并非没有挑战。仓库大小可能会变大，尽管现代 Git 可以很好地处理这一点。CI 需要智能地只构建更改的项目。访问控制更加微妙——无法只授予对仓库一部分的访问权限。而且工具设置比简单的单项目仓库更复杂。

对于大多数团队来说，代码共享和原子提交的好处超过了挑战。关键是使用正确的工具，并建立关于如何组织仓库的明确约定。