刚才看了一篇文章, 虽然写的有点早，但是还是有一些收获，尤其是目前的工作中也有面临类似的一些问题。
例如整个产品由许多的前端模块组成，有些是需要打包部署的业务模块，有些是公共的 npm 模块，当 npm 模块被更新后会在 npm 仓库中发布一个新版本，然后通知所有依赖这个模块的所有业务模块升级一下版本号。虽然细粒度的模块拆分方便了分工协作，但是在维护起来非常繁琐，而且经常也会因为某个业务模块没有更新而导致行为不一致或者 BUG 没有修复彻底。
感觉单一仓库的代码管理方式是天然能解决该问题的，但是除了 Google 是这种方式外，国内没有听说任何哪一家是这搞样的，全部迁移到这种方式貌似在公司里也是很难推广的。但倒是可以尝试在一定范围内单一仓库，比如说一条产品线的所有前端模块单一仓库进行管理。
下面是文章的一个摘要，可以参考。
组织简单
- 如果使用多个仓库，面临如何定义一个项目的问题，到底是一个项目作为一个 repo，还是多个相关的项目作为一个 repo。因此有时不得不出于开销的原因拆分或者合并 repo。
- 单一仓库方便快速定位到任意项目。
- 单一仓库方便安装开发环境，构建以及测试。
方便的依赖管理
- 如果使用多仓库，项目的依赖需要有版本的管理，虽然听起来理所应当，但是在实际操作中多数的解决方案是非常累赘繁琐的，会引入很多额外的开销。
- 如果是单一仓库，所有的项目在全局有一个唯一的版本号。
工具
- 因为简化的项目定位以及依赖管理，使得编写工具特别简单。工具不需要理解各个项目的依赖关系，只是读取、处理文件而已。
- 虽然听起来这貌似不太重要，但是在 Google 的实践已经证明了使用但一仓库对于软件的构建来说是多么简单的一件事情。而且在 Google 开源 bazel.io 之前，Facebook 和 Twitter 的工程师也已经在努力做同样的事情了。
- 当然构建系统并不是唯一从单一仓库中获益的事情，例如：
- 跨项目的静态代码分析，无需做任何额外的工作。
- 跨项目的继承测试
- 遍历的代码检索
跨项目变更
- 如果使用多个仓库，跨项目的变更时非常痛苦的，需要大量的人力手工合作开销。光更新上游模块的依赖管理信息也是个很头痛的事情。
- 使用单一仓库，只需要在一次提交中重构API以及所有调用方即可。