A monorepo is the practice of keeping many projects, libraries, or services in a single version-control repository rather than splitting them across many small repositories. The opposite arrangement, with each component in its own repository, is sometimes called a multi-repo or polyrepo setup.
The best-known example is Google. Its 2016 Communications of the ACM paper, “Why Google Stores Billions of Lines of Code in a Single Repository,” describes a custom-built monolithic source repository that acts as “a common source of truth for tens of thousands of developers around the world.” The paper lays out the infrastructure, workflows, advantages, and trade-offs of running a codebase at that scale in one place.
The appeal of a monorepo is unified change and dependency management. With all code in one repository, a single commit can update a library and every caller of it at once, dependencies are easy to discover, and there is one consistent view of what the whole system looks like at any moment.
The cost is tooling complexity. As the Google paper and the trunk-based development site both note, a repository holding billions of lines requires purpose-built build, version-control, and code-browsing systems that ordinary tools cannot handle. A monorepo therefore trades that engineering investment for coordinated, atomic changes across an entire organization’s code.