Monolith、MultiRepo和Monorepo 这三个都是代码管理的不同策略。我理解的这三种策略是一个演变过程，随着应用体量的增长和团队人员增加为了让代码有更好的可重用性和团队协作性而衍生的管理策略。
下面就是单独就每个阶段单独解释一下
阶段一 Monolith
单仓库巨石应用， 一个仓库维护着项目代码，一个简单的新项目应该初步都是这个阶段，随着迭代业务复杂度的提升，项目代码会越来越多，越来越复杂，大量代码构建效率也会降低，而且随着人员增长代码冲突也越来越常见，最后导致维护困难、测试困难、上线困难。
阶段二 MultiRepo
多仓库多模块应用，单一仓库管理的项目代码量太多时可视情况根据业务将项目拆解成多个模块，并用多个 Git 仓库管理，模块解耦，降低巨石应用的复杂度，每个模块都可以独立编码、测试、发版，代码管理变得简化，构建效率也得以提升，开发人员之间协作也会更加顺畅。
阶段三 Monorepo
单仓库多模块应用，随着业务复杂度的提升，模块仓库越来越多，MultiRepo这种方式虽然从业务上解耦了，但增加了项目工程管理的难度，随着模块仓库达到一定数量级，会有几个问题：跨仓库代码难共享；分散在单仓库的模块依赖管理复杂（底层模块升级后，其他上层依赖需要及时更新，否则有问题）；增加了构建耗时。于是将多个项目集成到一个仓库下，共享工程配置，同时又快捷地共享模块代码。
总结
以上是这三个阶段的演变，个人认为也不一定是最后的第三阶段就是最好的管理策略，新项目也不会直接从第三阶段开始，三种策略都是为了解决 业务的复杂度和团队人员增长而产生的问题的，所以一个好项目不一定是用的最新的前沿技术，但是一定是最符合当前业务的。
- THE END -
最后修改：2024年6月24日
非特殊说明，本博所有文章均为博主原创。
