Byte-Sized Design

Byte-Sized Design

Share this post

Byte-Sized Design
Byte-Sized Design
Google Went Monorepo And Never Looked Back

Google Went Monorepo And Never Looked Back

All the Code All in One Place

Byte-Sized Design's avatar
Byte-Sized Design
May 28, 2023
∙ Paid
8

Share this post

Byte-Sized Design
Byte-Sized Design
Google Went Monorepo And Never Looked Back
Share

TLDR;

Google has way too much code in their codebase… and they chose to put it all in one repository. Anyone Google employee has access to all of Google code from Pixel, to Youtube, to Google Cloud.

Google made it work because working with a single repository is simpler. It’s simpler dealing with less dependency management, and having a single source of truth.

Gimmie Context

Lets take it back to 2015 and talk about how Google stored 2 billion lines of code in 9 million source files. They store all of that in a single repository.

That’s right, all of Google’s 40+ million commits and code changes are all on a single code repository. It scales, it works, and it has advantages.

They do it all with trunk-based development, where everyone writes to HEAD or the most recent version of code.

But How Does This Actually Work for Googlers?

To do all this at scale, Google does 2 things:

  1. Trunk-based development

  2. Coding Workflow

Trunk-Based Development

Google writes all their code using trunk-based development. This just means everyone works on HEAD, or the latest code in their codebase, and makes changes on top of that.

Everywhere else? Make new branch, add changes to it, and merge that branch to the main branch. But Google doesn’t do that here.

Coding Workflow

Making a code change? Google has internal systems to rebuild everything that code change touched. If the build breaks, it’s not going through.

Before you even get to that point, another engineer needs to review, comment, and approve that code. Code changes don’t go anywhere without approval.

And who needs to approve? Someone who actually owns that area of code. Google has programmatic ownership checks for coding directories to make sure random Google cloud engineers aren’t approving changes to Youtube algorithms

They Do It All in a Single Repo… But Why Though?

Glad you asked, here’s the advantages

Single source of truth

We’re all reading the same book and things don’t go stale. If other Google teams want to reuse shared code, they don’t have to worry about which versions they’re using. It’s all here and it’s all available.

Better Dependency Management

Everyone is using the same version of a dependency. If there needs to be an upgrade, you’ll know immediately if the upgrade broke something. It’s just easier to upgrade everything all at once to use the same versions.

Atomic Changes

Changes aren’t split between different areas of code. If we need to rename everything, we can do it all in a single code change without being split between multiple repositories.

Keep reading with a 7-day free trial

Subscribe to Byte-Sized Design to keep reading this post and get 7 days of free access to the full post archives.

Already a paid subscriber? Sign in
© 2025 Byte-Sized Design
Privacy ∙ Terms ∙ Collection notice
Start writingGet the app
Substack is the home for great culture

Share