HackerTube.dev

Why Google Stores Billions of Lines of Code in a Single Repository

@Scale · 316.8K views · 2015-09-14 · 30:50

Open on YouTube ↗

If playback is restricted in your region, try opening the original video. Use Mark watched to add it to your marked videos.

Overview

Rachel Potvin describes the scale of Google's codebase and its custom monolithic source repository. She explains the reasons for the monorepo model, the tooling that makes it workable, and its tradeoffs.

On Hacker News

The go-to reference in monorepo and trunk-based development discussions, recommended as a firsthand account of how Google manages source control.

Recommended by 2 HN people across 3 months · HN mentions 2016–2022

Topics

Testing, debugging & developer toolsSoftware architecture & design
Search by tags
monorepogooglesource controltrunk-based developmentdev tools

What people said

kyrra · 2022-05 · Recommendation

Googler opinions are my own. I also highly recommend this ACM article talking about our source control from 2016. [LINK] There's also a YouTube video which is linked from the wired article that is good. [VIDEO]

Read the original HN comment ↗
kyrra · 2017-01 · Recommendation

Google doesn't use perforce anymore. They have a custom in-house SCM that has various interfaces wrapped around it. I'd recommend this video that describes it. [VIDEO]

Read the original HN comment ↗
twotwotwo · 2016-07 · Recommendation

It's common practice for folks building Go binaries (but not libraries) to check in the code for their dependencies. So whenever you build Docker, you get the same thing unless Docker made a change (either by changing Docker itself or explicitly checking in an upgrade to a dep). There are a few nice things about it; vendoring means you won't have a dependency on other repos or archives being available, and if you're a binary maintainer you can see source changes in your own code and that of your dependencies side-by-side if you're, say, investigating a bug that came up between certain revisions. The not-so-nice things are pretty much what you'd think. There isn't a command to say "give me upgrades, but not ones that the author flagged as breaking changes". If you're writing a _library_ that is depended on by other _libraries_ there is no one conventional way to safely do breaking changes, so there's a lot of effort to avoid those changes plus sometimes hacks like different repo paths for different versions. Part of the history is that, internally, Google's got one version of third-party code in the latest rev of their source control tree, by company policy. You upgrade something for one, you upgrade it for the whole codebase. Sounds daunting, but they have lots of testing, canary servers, and so on to catch problems. There is a great talk about some of this by Rachel Potvin (can't recall if it covers the third_party/ stuff specifically): [VIDEO] So Go's initial model didn't c

Read the original HN comment ↗

Sources

Video by @Scale, played through YouTube.

Data and selection notes

HN summaries and labels may contain AI errors. HN dates refer to discussions, not video publication.

HN Library: HackerTube export (2026-10-31) and open-index/hacker-news. Upstream summaries and classifications may contain AI errors.

Views, duration and playback status refresh separately from the published catalog. When an update fails, existing data remains visible.

Selection checks
  • SaaS & AI candidates: Topic keywords do not match
  • Editor-approved picks: Editorial review is required

Rule matches identify candidates. They do not guarantee video quality or financial results.

About the library and its sources