Monorepo

A monorepo keeps many projects, packages, or services in one version-control repository instead of one repo per project. Google, Meta, and Microsoft keep almost all of their code this way, including billions of lines.

The gain for a large org is coordination. One commit can touch many packages. Shared tooling, tests, and CI apply everywhere. You can rename a function used in ten packages in a single change. Dependencies live at the root instead of across a web of version pins.

The pain scales with size. You cannot rebuild everything on every change. Bazel, Nx, and Turborepo rebuild only what changed. Ownership gets messy when many teams share one tree. IDEs slow down when the file count hits the millions.

Monorepo versus many repos is a coordination choice. One repo means tighter coupling through shared code. Many repos mean looser coupling through versioned APIs. Pick based on how often you need an atomic change across packages, not based on a slogan about how Google works.

Access control and code owners files become the real org chart. Without those, everyone can touch everything, and they will. Google's 2016 CACM paper describes a company-wide monorepo. Many startups copy the idea with Nx, Bazel, or Turborepo at much smaller scale.