仓库管理

一个应用程序项目的管理大致分为三种：

• Single-repo Monolith
• Multi repo
• Mono repo

他们各有各的适用场景，并不是说谁好，谁不好。

Mono Repo

Mono Repo 指的是：

Using single git repository to manage multiple apps and libraris.

之所以使用单个仓库而不使用多个仓库，是因为对一些项目来讲，仓库变动的代价大于代码变动。

例如，项目里，许多逻辑是一样的，都会进行某写很简单的小操作，但是需求变化导致这一些操作发生变化了，必须去改这个操作。但因为是不同的仓库，所以在修改时需要一次修改多份。

你可能会想，把重复的那个操作，另外拉出来单独创建一个小的 libs 存储库，直接改 libs 的东西即可，那流程就会变成改，因为我们提到，仓库的变动代价是很大的：

• 抽离 libs 到新建仓库
• 重构每一个使用该仓库的代码，让他们在当前项目中引入该 libs 依赖，这将影响每个团队的工作流

因为仓库被切的太清楚，而小的改动也需要修改仓库，进而导致影响下游仓库，进而影响仓库所属的下游团队的开发流程。当程序大到一定程度，仓库之间的依赖和版本管理就构成了一个有向图，需要耗费单独的时间和人力，穿插在项目开发和部署中，进行维护。

再例如，多个仓库进行的类似的模块的开发，比如都是写页面，A 仓库写主页，B 仓库写搜索后页面，他们实际上应该用到的项目配置文件是一样的，因为都是写页面，公司一定有一套固定的约束规范。这个配置文件却在每个写页面的仓库都被放置一份...总不能把新建一个仓库，里面就放一个配置文件，然后打上一个"这是我们公司写页面的规范"的 readme 吧...反观把多个页面的开发都放到一个前端仓库中，就很方便了，只需要把语法规范的配置文件放在根目录即可，vscode 能自动去读。

也就是说，核心思想就在于，对一些项目而言，对仓库的进行操作和管理仓库之间的变动依赖，代价是大于单一仓库内代码的管理的。

缺点

• 约定优于配置

多个模块的开发团队公用一个仓库，意味着 A 模块的开发人员可以去修改 B 模块目录下的代码。这可能会引起一些问题，应当进行约定，自己的团队只能动什么文件夹，只能用什么文件。

实际上，换个思路，配置也可以看做是一种强约定，只不过这个约定是强制的。再编写一个配置文件和配套插件要求不同文件夹不可以互相操作也不是不可以，只不过成本很高。