Overview
Stay with separate repos when teams ship on independent schedules, need distinct access controls, or publish packages consumed by outsiders. The tax arrives as coordinated multi-repo changes and version drift; the tradeoff is weighed in monorepo-vs-polyrepo.
Definition
Polyrepo (also “multi-repo”) is a repository strategy where each project, service, or library lives in its own version-controlled repository. Each repo has independent history, CI pipeline, dependency graph, and release cycle. Cross-project changes require coordinated PRs across multiple repos and version bumps via package registries. Polyrepo is the historical default for open-source ecosystems and for organizations with strong team boundaries.
When it applies
Use polyrepo when teams are independent, projects ship on different cadences, and most changes stay inside one repo. Avoid it when frequent cross-project refactors expose the seams between repos.
Example
A company ships its public API client SDK from acme/api-client and its server from acme/api-server. Each repo has its own CI, semver releases, and changelog. A breaking API change requires a PR to api-server, a release, then a follow-up PR to api-client to bump the dependency.
Citing this term
See Polyrepo (llmbestpractices.com/glossary/polyrepo).
Related
- monorepo - the contrasting layout strategy.
- monorepo-vs-polyrepo - the head-to-head comparison.
- monorepo - the deep-dive on the monorepo side; sets context for the choice.
- project-structure - the broader project layout discipline.
- semantic-versioning - the versioning scheme polyrepos rely on for coordination.