大概知道Monorepo是什么，但是又不是那么的清楚。。。（逃

采用monorepo以后整个项目的的版本号迭代和tag会变得非常频繁，非常想知道如何去控制的

tag 分子 repo 打标呢？比如加子 packageName 的前缀。版本号可以只用子 package 独立的，不用项目整体的。

如果关注 lerna (monorepo的一个实现)的话可以看到他其实有很多相关管理工具，比如lerna-changelog的并不会出现tag前面是packageName分支的情况出现。

可以参考 babel 和 react-router

monorepo 感觉更适合内聚性比较强的工具类、框架类工程，例如react相关、 Angular相关，一般发布会有一系列的依赖同步更新；同时这种工程发展是可控的，不会随意膨胀，所以库的体积也是可控的。

业务类的工程代码管理感觉不适合用 monorepo，
一是业务代码膨胀很快，不可控，体积会变很大，迟早要拆；
二是用了 monorepo 自动化发布不好搞，业务一般是要求能独立发布，互不影响，多工程好搞自动化，只要关心repo地址就行，剩下的事情外部工具直接执行repo内的ci文件就行，monorepo 的话是不是要写很多文件夹的逻辑；
三是业务类的工程往往和组织架构相关，不同的一群人各做各的业务，monorepo 不好做细粒度的权限管理，目前 github gitlab 的权限管理只能到仓库级还不能到目录级；
四是可以不同的业务用不同的技术实现，比如订单相关可以用 react，用户相关可以用 Angular，目前monorepo 的管理工具对多技术体系的支持不是那么好；
五是多工程的依赖完全是独立的，互不影响，给了一些升级依赖延迟的余地。现实世界中业务有些可能就是需要一些旧的依赖，并且还改不动，独立工程的话，可以就先活着，慢慢死去或另起工程更换。

但是多工程需要很强的基建基础，要不然人工维护很痛苦

git分支管理会变的很混乱啊，这个有什么办法吗

monorepo 感觉更适合内聚性比较强的工具类、框架类工程，例如react相关、 Angular相关，一般发布会有一系列的依赖同步更新；同时这种工程发展是可控的，不会随意膨胀，所以库的体积也是可控的。

业务类的工程代码管理感觉不适合用 monorepo，
一是业务代码膨胀很快，不可控，体积会变很大，迟早要拆；
二是用了 monorepo 自动化发布不好搞，业务一般是要求能独立发布，互不影响，多工程好搞自动化，只要关心repo地址就行，剩下的事情外部工具直接执行repo内的ci文件就行，monorepo 的话是不是要写很多文件夹的逻辑；
三是业务类的工程往往和组织架构相关，不同的一群人各做各的业务，monorepo 不好做细粒度的权限管理，目前 github gitlab 的权限管理只能到仓库级还不能到目录级；
四是可以不同的业务用不同的技术实现，比如订单相关可以用 react，用户相关可以用 Angular，目前monorepo 的管理工具对多技术体系的支持不是那么好；
五是多工程的依赖完全是独立的，互不影响，给了一些升级依赖延迟的余地。现实世界中业务有些可能就是需要一些旧的依赖，并且还改不动，独立工程的话，可以就先活着，慢慢死去或另起工程更换。

但是多工程需要很强的基建基础，要不然人工维护很痛苦

不太明白你说的第四点和第五点。关于第四点，各个packages自己可以有自己单独的npm script，自己写自己的，不管其他的package啥事儿。关于第五点，同样，各个package如果用了同一个库的不同版本，只需要在package内部的workspace安装这个package的依赖就好了，能复用的依赖自动会上升到最外层的package.json.

monorepo 感觉更适合内聚性比较强的工具类、框架类工程，例如react相关、 Angular相关，一般发布会有一系列的依赖同步更新；同时这种工程发展是可控的，不会随意膨胀，所以库的体积也是可控的。
业务类的工程代码管理感觉不适合用 monorepo，
一是业务代码膨胀很快，不可控，体积会变很大，迟早要拆；
二是用了 monorepo 自动化发布不好搞，业务一般是要求能独立发布，互不影响，多工程好搞自动化，只要关心repo地址就行，剩下的事情外部工具直接执行repo内的ci文件就行，monorepo 的话是不是要写很多文件夹的逻辑；
三是业务类的工程往往和组织架构相关，不同的一群人各做各的业务，monorepo 不好做细粒度的权限管理，目前 github gitlab 的权限管理只能到仓库级还不能到目录级；
四是可以不同的业务用不同的技术实现，比如订单相关可以用 react，用户相关可以用 Angular，目前monorepo 的管理工具对多技术体系的支持不是那么好；
五是多工程的依赖完全是独立的，互不影响，给了一些升级依赖延迟的余地。现实世界中业务有些可能就是需要一些旧的依赖，并且还改不动，独立工程的话，可以就先活着，慢慢死去或另起工程更换。
但是多工程需要很强的基建基础，要不然人工维护很痛苦

不太明白你说的第四点和第五点。关于第四点，各个packages自己可以有自己单独的npm script，自己写自己的，不管其他的package啥事儿。关于第五点，同样，各个package如果用了同一个库的不同版本，只需要在package内部的workspace安装这个package的依赖就好了，能复用的依赖自动会上升到最外层的package.json.

这 2 点是可以通过 yarn workspace 之类的方案解决的，之前写这个的时候是因为我们选了一个 monorepo 解决方案 nx，它不是这种方式。

如果公司的项目有依赖二次封装的组件库和一些需要复用代码的业务组件或者工具包时，还会被其他部门或者其他项目使用，monorepo很适合，他的坑几乎都有对应的工具踩了，还支持统一跑测试用例，整合下文档，整体项目上一个台阶，结构清晰，但是复杂度同理，对新人不太友好，但是我们有自动化测试，能规避很多基本错误