monorepo仓库管理方式探秘

前言

随着功能和业务量级的飙升，前端代码量级也越来越大，管理运维的成本也进一步增加。
代码仓库的运营管理挑战也浮出水面。
主流方案有两种：一是multirepo式的分散式的独立仓库，二是monorepo式的集中管理，各有千秋，下面就结合实际场景一起深入了解下。

分散式管理：multirepo

即按照功能或者其他维度，将项目拆分为不同模块单独维护于各自仓库中。

使用场景

对于敏捷迭代快速开发的新需求，常规做法就是每个模块对应一个仓库，新的需求进行归类，可归入已有仓库则进行迭代，不满足则新建仓库。

优势

1.灵活

不同模块独立维护，与其他模块天然隔离。各个模块可以选择适合自己的风格、工具等。

2.安全

得益于模块的拆分，权限控制较为自然。
开发时只关注相关部分，不会误操作其他内容。
发布上线，对其他模块无感知。

问题

作为传统的管理组织方式，发展演进这么久，必然会存在一些限制。突出体现在协作和管理成本上。

1. 管理成本

常见的项目交接时，每个人都负责了一堆项目、账号等，只能手动梳理，还存在漏掉的可能。我当初经历过几次大的调整，交接的真是一脸懵逼和心痛。来个需求才发现还有个仓库一直处于遗忘的角落。

2. 协作成本

涉及多个项目开发时，本地开发需要打开多个IDE在其中切换。
对于本地调试等也是个繁琐的过程，虽然存在npm link等方式。

3. 依赖升级

这种场景一般出现在依赖的核心模块上，特别是自行开发的基础依赖，不得不升级时简直一言难尽，数目直逼上百的项目，每个都要修改发布一次。

上面说的是业务模块，对于开源或者公司内部基础性工具，升级这里的问题更显著一些。对于程序员俩说，出现问题解决问题就是，因此集中式的管理模式就出现了。

集中式管理：mon