编程与软件工程cacm.acm.org编辑精选
谷歌为何将数十亿行代码存于单一仓库（2016）
Why Google Stores Billions of Lines of Code in a Single Repository (2016)
2016 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇 CACM 文章解释 Google 为什么把数十亿行代码放进同一个仓库，以及支撑这种模式所需的工具、流程和文化。文章讨论单体仓库在统一依赖、跨项目重构和原子变更上的优势，也强调它并非没有代价。
为什么经久不衰：它是理解 monorepo 权衡与 Google 工程实践的经典入口，尤其提醒读者：Google 的做法依赖大量专用工具和组织投入，不能简单照搬。
HN 评论精选
monorepo 的成功依赖大量工具投入，不能盲目模仿。
看到这篇文章就想着“啊！我也该迁到 monorepo”的人让我难受。我见过好几次，他们似乎都忽略了一点：Google 在 monorepo 工具上投入了数千小时。把很多项目塞进一个 git 仓库却不投资工具，体验不会好。
hobls查看英文原文
I feel terrible for anyone who sees this and thinks, “ah! I should move to a monorepo!” I’ve seen it several times, and the thing they all seem to overlook is that Google has THOUSANDS of hours of effort put into the tooling for their monorepo. Slapping lots of projects into a single git repo without investing in tooling will not be a pleasant experience.
源码管理与依赖管理应分开考虑，同仓库也可以配合版本化依赖。
是不是很多人把源码管理和依赖管理混为一谈了？这两者不必绑定。比如 Python 项目 X 依赖项目 Y，可以让它们分处不同 SCM 仓库并通过 requirements.txt 指向托管产物，也可以放在同一仓库里直接引用源码，或者同仓库但仍用 requirements.txt 锁定某个版本。最后一种既能享受 monorepo 的搜索、版本管理等便利，又能控制依赖。顺便问：Google 内部工具支持细粒度权限吗？
jgibson查看英文原文
Is it just me, or are a lot of people here conflating source control management and dependency management? The two don't have to be combined. For example, if you have Python Project X that depends on Python Project Y, you can either have them A) in different scm repos, with a requirements.txt link to a server that hosts the wheel artifact, B) have them in the same repo and refer to each other from source, or C) have them in the same repository, but still have Project X list its dependency of project Y in a requirements.txt file at a particular version. With the last option, you get the benefit of mono-repo tooling (easier search, versioning, etc) but you can control your own dependencies if you want. edit: I do have one question though, does googles internal tool handle permissions on a granular basis?
单体仓库便于跨内核和用户空间做破坏性整体变更。
这并不罕见。OpenBSD、NetBSD 的仓库某种程度上就是单体的，而且有优势。比如 OpenBSD 5.5 发布说明称已为 2038 年做好准备，而 Linux 当时还没完全解决 y2038。这个问题涉及内核和用户空间的 ABI 改动，OpenBSD 因为内核和用户空间在同一仓库一起构建，可以一次性改完。单体仓库让“大改 A、重建整个世界、看哪里坏了、修补、重复直到没有回归、提交”更容易。
senozhatsky查看英文原文
Well, it's not so uncommon. For instance, OpenBSD, NetBSD repos are sort of monolithic. And, believe it or not, there are some advantages. For instance, let's take a look at OpenBSD 5.5 [0] release notes: > OpenBSD is year 2038 ready and will run well > beyond Tue Jan 19 03:14:07 2038 UTC OpenBSD 5.5 was released on May 1, 2014. While Linux is still "not quite there yet" y2038-wise. y2038 is a very complex issue, while it may look simple - time_t and clock_t should be 64-bit. This requires changes both on the kernel -- new sys-calls interfaces [stat()], new structures layouts [struct stat], new sizeof()-s, etc. -- and the user space sides. This, basically, means ABI breakage: newer kernels will not be able to run older user space binaries. So how did OpenBSD handle that? The reason why y2038 problem looked so simple to OpenBSD was a "monolithic repository". It's a self-contained system, with the kernel and user space built together out of a single repository. OpenBSD folks changed both user space and kernel space in "one shot". IOW, a monolithic repository makes some things easier: a) make a dramatic change to A b) rebuild the world c) see what's broken, patch it d) while there are regressions or build breakages, goto (b) e) commit everything [0] http://www.openbsd.org/55.html?hn [UPDATE: fixed spelling errors... umm, some of them] -ss
Google 内部实践并非文章描述的整齐统一，构建系统多样且访问并非完全开放。
在 Google 工作的 16 个月里，我分别用 shell 和 Make 做 Android、用 Portage 做 ChromeOS、用 Ninja 做 Chrome、用 Blaze 做 google3（即 monorepo），但常嵌套其他构建系统。构建系统多样使换项目时学习曲线很陡。入职时说所有代码都在 monorepo、每个工程师都能访问所有代码，但事实并非如此；我觉得 Google 的构建系统多样性反而比我工作过的其他地方更多。
OneMoreGoogler查看英文原文
During my 16 month tenure in Google, I worked on: 1. Android, using shell and Make 2. ChromeOS, using Portage 3. Chrome browser, using Ninja 4. google3 (aka "the monorepo") officially using blaze (but often there were nested build systems - I remember one that used blaze to drive scons to build a makefile...) The diversity of the build systems significantly steepened the learning curve when switching projects. During orientation, they told me "All code lives in the monorepo, and every engineer has access to all code", but this turned out to be not true at all. If anything it was the opposite: more build system diversity at Google than at other places I worked.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选