什么是真正的单体代码库？

在软件公司中，经常会出现关于是否应该采用“单体代码库”（即“公司所有代码存放在单一版本控制仓库中”）的讨论。很多人做这个决定是基于Google的代码存储方式。

作者曾在拥有先进单体代码库的Google和拥有先进多仓库系统的LinkedIn的开发者生产力团队工作，他指出：人们通常认为单体代码库具备的许多有价值特性，实际上与源代码仓库的数量无关。

单体代码库的六大核心概念

假设有两个独立项目A和B，需要同时修改这两个项目。单体代码库能保证可以原子性地同时向这两个项目提交更改。这在需要同步修改才能保证功能完整的场景中尤为重要，比如修改库函数签名时需要同时更新调用该函数的所有应用。

所有代码都存在于统一的目录结构中。在开发过程中，如果项目A存储在仓库的/path/to/project/A，项目B存储在/path/to/project/B，那么检出时它们就会位于相邻目录。这种标准化结构简化了多项目协同开发。

单一目录结构使得代码搜索工具能够直接浏览目录，并使用单一工具搜索整个仓库。虽然多仓库系统也可以通过UI工具或虚拟文件系统实现统一视图，但由于缺乏原子性的“head”概念，实现会更复杂。

开发者无需思考“应该从哪个仓库检出代码”，只需关注需要检出的具体代码。所有提交都指向同一个仓库，同时提供完整的历史提交视图，便于调试和变更追踪。

在大多数单体代码库中，版本控制系统跟踪的最小单元是文件。某些系统还支持单独检出单个文件，这对于大型仓库来说是重要的生产力特性。在Google的代码库中，依赖的最小单元甚至是文件级别，构建系统可以精确识别文件间的依赖关系。

通常单体代码库会强制要求同一时间仓库中只能存在任何软件的一个版本。这简化了系统行为推理，避免了运行时多版本冲突问题。但这也带来了显著缺点：广泛使用的库升级困难，第三方库版本容易“卡死”在特定版本。

在单体代码库环境中，库的维护者如果提交了不兼容的更改，可能会破坏所有依赖项目的构建。这意味着库维护者必须承担升级工作的成本，而不能简单地将升级工作推给使用者。

“单体代码库”远不止是将所有代码放在一个仓库中。虽然这些概念在Google的单体代码库中得到了集中体现，但重要的是要认识到这些概念可以分离，并且可以在现有系统中分别实现。企业应该有意识地选择适合自身需求的技术方案。