Monorepos vs Polyrepos

A monorepo stores multiple, often independently deployable, projects — services, libraries, frontends — inside a single Git repository with a single unified history. A polyrepo strategy instead gives each project (or even each library) its own repository, its own history, and its own release cadence. Neither is universally correct; the choice trades off atomic cross-project changes, unified tooling, and simpler dependency management against repository size, access-control granularity, and the blast radius of a single misconfiguration. Companies like Google and Meta famously run enormous monorepos with custom tooling built specifically to make Git (or, in Google's case, a purpose-built alternative) scale to that size, while many organizations with more standard needs find polyrepos simpler to reason about and secure.

The headline benefit of a monorepo is atomic cross-cutting changes: if a shared library's API changes, every consumer in the repository can be updated in the same commit, reviewed in the same pull request, and merged together — there is no window where a breaking change has shipped to the library but not yet propagated to callers, and no need to coordinate version bumps across repositories. Code search and refactoring tools naturally see the whole codebase at once. Dependency management also simplifies: instead of publishing an internal library to a package registry and bumping version numbers across every consumer, code simply references the library's current path in the same tree. The tradeoff is that repository size, clone time, and CI cost all grow with the whole organization's codebase rather than with one team's slice of it, which is why large-scale monorepos typically require investment in sparse checkouts, build caching, and custom CI that only builds what actually changed.

A polyrepo keeps each project's history, issue tracker, access controls, and release cycle independent. A team can move fast on its own service without CI runs for unrelated projects slowing it down, and permissions can be scoped precisely — a contractor working on one microservice never needs read access to the rest of the organization's code. The cost shows up at integration boundaries: a change to a shared library now requires publishing a new version, and every downstream repository must separately update its dependency version, which can lag for months and produce exactly the kind of version-skew problems monorepos avoid. Coordinating a change that spans several repositories also means opening several pull requests, which cannot be reviewed or merged as one atomic unit — someone has to track that all of them land together, often manually.

Some organizations land between the extremes: polyrepos for genuine deployment and ownership boundaries, paired with shared tooling (a common CI template, a shared linting config repository, tools like git submodules or subtrees, or a package registry with strict internal versioning discipline) to recover some of a monorepo's coordination benefits without merging everything into one history. There is no single right answer — the decision should follow team topology and how frequently code genuinely needs to change atomically across project boundaries, not a general belief that one approach is inherently superior.