Jaké jsou strategie monorepo versus polyrepo?

Question

Accepted Answer

**Monorepo** (jeden repozitář pro více projektů/služeb) a **polyrepo** (oddělený repozitář na projekt) jsou dvě strategie pro organizaci kódu napříč více projekty. Každá má významné kompromisy ovlivňující spolupráci, nástrojování a škálování — jejich pochopení informuje důležitá architektonická rozhodnutí.

## Monorepo — jeden repozitář na vše

```text
Many projects/services/libraries in a SINGLE repository:
  ✓ SHARED code/libraries easy to use and refactor (one place, atomic changes)
  ✓ ATOMIC commits across projects (change an API and all its consumers together)
  ✓ Unified tooling, versioning, CI; consistent standards; easy cross-project visibility
  ✓ Simplified dependency management (one version of shared code)
  ✗ Repo can get HUGE (needs scaling tooling — sparse checkout, build caching)
  ✗ Needs sophisticated build/CI tooling (Nx, Turborepo, Bazel) to be efficient
  ✗ Broad access; CI must be smart (only build what changed)
→ Used by Google, Meta, etc. (with heavy tooling investment).
```

## Polyrepo — jeden repozitář na projekt

```text
Each project/service/library in its OWN repository:
  ✓ Clear OWNERSHIP and boundaries; independent versioning/releases/CI
  ✓ Smaller, focused repos; granular access control; independent teams
  ✗ SHARED code is harder (publish/consume packages; version coordination)
  ✗ Cross-cutting changes span MANY repos (coordinate multiple PRs — painful)
  ✗ Potential inconsistency across repos (tooling, standards drift)
→ Common default; fits independent services/teams.
```

## Výběr

```text
MONOREPO → tightly-coupled projects, heavy code sharing, want atomic cross-project
  changes and unified tooling, willing to invest in scaling tooling
POLYREPO → independent projects/teams, clear boundaries, independent release cycles,
  simpler per-repo needs
→ No universal answer; depends on the org, coupling, scale, and tooling investment.
```

## Proč je to důležité

Pochopení strategií monorepo versus polyrepo je cenné znalosti na senior úrovni pro **kvalitní rozhodování o architektuře organizace kódu**, což je významná volba s širokými důsledky, a proto je užitečná pro senior/architektonické role.

Dva přístupy — **monorepo** (více projektů v jednom repozitáři) a **polyrepo** (oddělený repozitář na projekt) — představují fundamentálně odlišné organizační filozofie se skutečnými kompromisy. Výhody **monorepo** (snadné sdílení kódu a refactoring, **atomické cross-project commity** — změna API a všech jejích spotřebitelů najednou, jednotné nástrojování a standardy, zjednodušená správa závislostí) jej činí mocným pro těsně související projekty s velkým sdílením kódu, ale vyžaduje významné investice do **nástrojování na škálování** (Nx, Turborepo, Bazel, sparse checkout, smart CI) pro efektivní zpracování velkého repozitáře. Výhody **polyrepo** (jasná vlastnictví a hranice, nezávislé verzování a cykly vydávání, menší zaměřené repozitáře, granulární přístup) vyhovují nezávislým projektům a týmům, ale činí **sdílení kódu obtížnějším** (publikování/spotřeba balíčků, koordinace verzí) a **cross-cutting změny bolestivými** (koordinace PR across mnoha repozitářů).

Pochopení těchto kompromisů a způsobu **výběru** (monorepo pro těsně související, kód-sdílející projekty ochotné investovat do nástrojování; polyrepo pro nezávislé projekty a týmy s jasným rozdělením) odráží architektonický soud očekávaný na senior úrovni — uznání, že neexistuje univerzální odpověď a správná volba závisí na vazbě, měřítku, struktuře týmu a investicích do nástrojování.

Poněvadž organizace kódu napříč více projekty je významné architektonické rozhodnutí ovlivňující spolupráci, nástrojování, škálování a autonomii týmu, a protože pochopení kompromisů monorepo/polyrepo informuje toto důsledné rozhodnutí, je pochopení strategií monorepo versus polyrepo cenné znalosti na senior úrovni pro architektonické rozhodování, často diskutované téma, kde pochopení kompromisů (spíše než dogmatické favorizování jednoho) odráží zralý soud očekávaný pro senior role formující způsob, jakým organizace strukturuje svůj kód.