1 代码仓库管理有哪些方式？ #
1.1 Monolith #
1.2 Monorepo #
Monorepo 将所有源代码组织在一个层次树中。相关的项目或组件可以分组在一起，使用户更容易发现项目之间的关系。 想象三个逻辑上不同的代码库，实现：
- macOS 应用程序；
- 应用程序提供的相同功能的命令行界面；
- 和一个打包存储库，用于将应用程序和CLI捆绑到单个 .pkg 文件中进行分发。
这三个项目通常会彼此分开修改，在某些情况下，甚至可能由完全不同的团队进行修改。
1.2.1 #
在 Manyrepo 中，这些可能被称为
如果构建项目需要引用其他两个项目的特定修订版，则每个项目都必须定义临时解决方案 (有时是git子模块，有时是通过克隆到构建目录并检查指定修订版，有时是更具创意的解决方案)。
子模块可用于实现同步多项目提交。然后只需浏览层次结构就可以发现这种关系。
<department/etc.>
└── <sub-team>
└── <project>
├── app
├── build
└── cli
1.2.2 简化依赖 #
在 Monorepo 中，很容易依赖另一个项目：只需使用层次结构中不同路径的代码即可。在 Google，这种依赖关系似乎是通过在其 Blaze（公开的Bazel）BUILD 文件中编码的构建依赖关系来跟踪的。当子树的依赖项都可以从BUILD 文件中提取，并且它的所有依赖项也在树内时，就可以确定完整的调用者集并在每次更改时运行他们的测试。
这个事实很重要，所以我要重申一下：对于 Monorepo，库版本控制不再被强调。相反，库应该维护稳定的 API，并在 API 必须更改时迁移其调用者。这取决于能够在整个世界状态中进行原子提交，这在 Manyrepo 中是不可能的。这也意味着需要非常复杂的依赖性跟踪或分析，以及出色的自动化测试。