Mono-repo还是Multi-repo?

2019-11-07大约9分钟

Git是个非常流行且好用的代码管理工具,一般情况下,我们建一个project,都会选择建一个Git仓库(repository),然后再给每个仓库建一个对应的CI任务来构建这个项目。

项目少的时候,这个没什么问题,但项目多的时候呢,就有点不太方便了。可能会遇到这样的问题,比如

  1. 建立并管理多个仓库,是比较繁琐的事情,往往需要多个人去参与,并且有时候搞不清,到底哪个仓库里面到底有什么代码。

  2. 可能要改多个仓库的代码,那么首先我需要先把这些仓库都挨个克隆(Clone)下来,然后每次改动前,为了减少不必要的代码冲突,我都需要把为每个仓库拉取最新的代码,好麻烦!

  3. 修改多个仓库代码的时候。需要先修改一个,仓库,然后再发布,发布完之后,再修改另外一个依赖的仓库。

这种情况,有一个词“multi-repo”来定义。也就是multiple repository的意思,即我们用多个仓库来管理我们的代码。

为了解决上面的一些问题,有个办法就是:用单个仓库来管理多个不同项目的代码。具体操作的话就是在这个仓库里的目录下面,给不同的项目建不同目录,这样每个目录就对应不同的项目。

当然,单个仓库管理所有的代码并不是解决所有问题的一个最终办法,而只是一个折中的办法。比如用多个仓库管理代码,可以灵活地给不同的用户分配不同仓库的权限,但是如果我们用一个仓库的话就无法给一个用户分配只能看到仓库中部分代码的权限。因此,在实际操作中,我们可能会把mono-repo与multi-repo结合起来,我们可以把具有相同权限的项目的代码放到一个仓库里面去,而如果想给不同用户分配不同权限的话,那么就会为他们建不同的仓库。

对于常见的开发语言,比如Java、C#,开发工具本身就带了Solution和Project这样的概念,那么使用Mono-repo是很自然的事情;但如果是在做JavaScript的开发,并且需要发布NPM包,由于每个仓库都需一个package.json文件,这些仓库之间的代码要互相引用,那么我们就需要用额外的第三方的库来管理我们仓库中的不同项目。比如Lerna.js就是一个很不错的工具。