Home Monorepo vs multi-repo

Max Heinritz

Monorepo vs multi-repo

Most Google engineers operate in a monorepo called google3 with phenomenal internal tooling. It was a joy to work there in the early 2010s, and I’ve heard that it keeps getting better. Google invests heavily in custom tooling for code search, file ownership, version control, testing, commit queue, code review, linting, etc. The code must flow.

So naturally in my jobs outside of Google I have been inclined to follow the monorepo approach and recapture that magic. But over time I’ve come to appreciate that most tooling outside of Google is built for multi-repo projects, and it’s best to embrace rather than fight the tooling. Here are some examples:

For future projects, I’m inclined towards:

The separate code bases are also a nice reminder about breaking changes – backend changes to add new API features should be merged and deployed before the frontend changes that use the new features are merged.