谷歌正在这样做，你为什么不呢？
信不信由你，谷歌是我们行业中最大的monorepo用户之一。这不是我编的，他们的代码库很庞大，你可能可以想象，而且有报告说他们有95%的代码库在同一个仓库里。
根据ACM.org的这篇文章，谷歌的主要仓库有近10亿个文件，而那是6年前的事了！他们不得不把这些文件分布在各个地方。他们不得不把它分布在许多数据中心，有一个自己的架构，以确保文件得到适当的复制和备份，以防这些数据中心之一发生灾难性的故障。
毕竟，代码可能是谷歌内部最大的资产，也许仅次于他们收集的实际数据。
但有趣的是，他们将大部分的代码保存在一个单一的存储库中。他们称之为 "Piper"，这是他们的Git版本，他们不得不编写它，因为Git不能满足他们的要求。
但抛开Piper不谈，你为什么要使用一个单库呢？
更容易看到
你知道当你开始实现那个实用功能的时候，你会有一种感觉，也许，在另一个项目中，有人已经实现了类似的东西？
那么，使用monorepos，回答这个问题要容易得多，因为有可能，如果这个函数已经被创建，它就是你的 repo 的一部分。如果你面对的是一个像谷歌那样的单库，即你在其中保留了多个稍微不相关的项目，那么这个函数很可能存在于一个实用项目中，可以被你单库中的任何项目使用和共享。
当然，这只是在所有使用单一项目的团队都遵循一定的规则，以确保共同的功能被输出，并且项目之间尽可能地相互隔离，互不依赖。在这种情况下，编码的最佳实践是最重要的，因为忽视它们可能造成的混乱肯定会破坏 repo。
但是，如果你真的遵循这些最佳实践，那么你就会有一个非常紧密和密切的工具和团队的 "社区"，在一起工作和协作。
改进合作
与之前的思路相同，团队间的合作在单版本中要容易得多。
当然，这里需要注意的是，只有在每个团队都遵循非常明确的规则的情况下，这才是真的。
单人项目不是让每个人 "做自己的事 "的地方，可以这么说。
想想看，这就像与你的公婆、几个朋友和他们的夫妇分享房子。每个人都支付完全相同的租金，所以它不像有一个单一的所有者来支配规则。但你也不能让每个人都像只有他们的房子一样生活，因为那样你就会互相碰撞。
当你的朋友的孩子试图在客厅里玩电子游戏时，你会试图吃午饭。当你有一个重要的约会时，他们会想洗一个长长的澡。
现在想象一下，但有密码。很可怕，不是吗？
现在想象一下，他们都有一套共同的家规，而且每个人都按这些规则生活。然后他们将形成一个小的，但组织良好的社区。这也是你可以从你的monorepo中得到的，只要每个人都遵守规则。
所以，看看周围吧，你现在是否在使用单行本？你是否有一套非常清晰、明确的规则要遵守？如果答案是 "没有"，那就要求有，或者自己定义，并努力得到每个人的认可。你越早建立起这个 "工作框架"，你就会越早开始享受monorepo的生活。
更好的标准化和代码重用
从上面的观点来看，一旦你成功地定义并让每个人都同意，monorepo的共同 "内部规则"，那么这些好处就会有机地出现。
当不同的团队在同一个代码库中从事不同的项目时，他们迟早会开始有类似的需求。而作为开发者，我们最讨厌的就是在周五下午发布到生产中去？没错，就是重新发明轮子。
我们讨厌它，我们不喜欢这样做。因此，当这些团队开始有他们自己领域内的通用需求时，他们就会开始关注并询问 "嘿，你们是否也需要这个，因为我们已经在做它的通用版本了"。
迟早，你会开始看到通用库和功能的出现。
由于同样的原因，编码标准也必须被定义。毕竟，如果你创建的代码将被他人重复使用，那么每个人都有机会从这些代码中获得最大的利益，就是按照相同的标准来写。
这样，你会更容易整合外部工具，分享团队成员，甚至在许多不同的情况下验证这些标准有多好。因此能够更快地获得反馈，并能够将其调整为一套标准，在其业务领域内对每个人都有效。
单一真理源
当你有同一个库的两个版本，而它们都不是由你自己的团队编写的，你怎么知道该用哪一个？谁来告诉你它们是否都是有效的，是否应该继续维护和开发，或者它们是否应该合并成一个？
谁拥有这个决定？
这就是为什么当你开始正确地利用多团队环境中的monorepo时，你会发现为你的代码保持一个单一的真理来源是最好的方法。
这很可能涉及到团队领导之间的一些经常性会议，以确保共同的代码输出（即创建新的共同库）得到适当的协调，避免重叠。
这甚至可能是一个好主意，有一个类似于 "通用库委员会 "的东西，最好是所有团队的代表聚在一起，负责协调这些新出现的通用工具的适当发布和维护。
或者，至少要确保所有的团队认识到这个GLC在通用代码方面的 "权威"，而不是为了追求速度而忽视它。因为，同样地，为了使事情在单体方案中达到最佳效果，必须遵守规则，否则就会出现混乱。
当涉及到组织相关项目的团队时，Monorepos肯定会带来很多好处。它们可以帮助你改善工作方式，用更少的代码来节省时间，甚至可以在项目之间更容易地分享开发人员。
如果你有一套非常明确的、被接受的规则，那都是真的。否则，单体可以成为一个真正令人头痛的公司。
根据我的观察和研究，我还想说，不管你信不信，公司越大，他们从一个执行良好的单一项目中得到的结果就越好。这就是为什么谷歌，在世界所有公司中，拥有世界上最大的monorepos之一。
想想看，你可能同意或不同意他们的产品和他们的数据隐私规则。但你不能争辩说，他们有一些相当大的项目，而且大部分项目都生活在同一个资源库中，这是令人震惊的事实。
你呢？你在你的公司里使用单库吗？你有什么特别的规则来使它发挥作用？
