Monorepo a multirepo: definice bez chybných zkratek
| Kritérium | Monorepo | Multirepo |
|---|---|---|
| Průřezové změny | Jeden commit nebo PR může pokrýt více projektů | Obvykle více repozitářů, verzí a PR |
| Závislosti | Snazší centralizace a společná pravidla | Větší nezávislost verzí |
| CI | Vyžaduje výběr podle grafu, cache a škálování | Menší přirozený rozsah pipeline |
| Přístup | Vlastnictví cest přes pravidla a review | Přirozená izolace na úrovni repozitáře |
| Nástroje | Více společných standardů | Více svobody pro projekt |
| Releasy | Mohou být nezávislé, potřebují orchestraci | Přirozeně oddělené pipeline |
Monorepo je jeden repozitář obsahující více logicky oddělených projektů, například aplikace, služby, knihovny nebo nástroje. Multirepo, také polyrepo, drží tyto části v samostatných repozitářích. Hranice repozitáře jsou hranice správy zdrojového kódu, ne automaticky hranice nasazení. [1][13][15]
Monorepo tedy může obsahovat mnoho nezávisle nasazovaných služeb, zatímco multirepo může obsahovat moduly jednoho velkého systému. Zaměňovat strategii repozitářů s monolitem nebo mikroslužbami vede ke špatným architektonickým rozhodnutím.
Co ukazuje výzkum Google: oba modely mají reálné výhody
Google Research mezi inženýry se zkušeností s oběma modely označil viditelnost celé codebase za významnou výhodu monorepa. Pomáhá hledat znovupoužitelná API, příklady použití a aktualizovat závislý kód při migracích. Oceňována byla také centralizovaná správa závislostí. [1]
Stejná studie uvádí výhody multirepa: větší volnost toolchainů, silnější hranice přístupu a větší stabilitu mezi projekty. Autoři také zdůrazňují význam kvality nástrojů kolem zvoleného modelu. [1]
Průřezové změny: nejjasnější praktická výhoda monorepa
Když jedna změna rozhraní vyžaduje současně upravit backend, frontend, knihovny a testy, monorepo může celou migraci obsahovat v jednom commitu nebo pull requestu. Google uvádí aktualizaci závislého kódu při migracích API jako důležitý přínos společného repozitáře. [1][2]
V multirepu se stejná změna často změní na sled kroků: upravit producenta, vydat verzi, aktualizovat konzumenty a koordinovat více pull requestů. Automatizace pomáhá, ale hranice repozitářů zůstávají hranicemi integračního procesu.
Závislosti a verze: centralizace proti nezávislosti
Monorepo usnadňuje sjednocování společných verzí závislostí a přímé odkazy mezi lokálními balíčky. Yarn Workspaces propojuje balíčky v jednom projektu a Constraints může v celém workspace vynucovat pravidla verzí nebo `package.json`. [13][14]
Multirepo dává jednotlivým projektům větší svobodu ve verzích a načasování aktualizací, ale společné knihovny se mohou mezi repozitáři rozcházet. Funguje dobře se stabilními kontrakty a řízeným publikováním artefaktů.
CI v monorepu: přebudovat vše při každém commitu je špatný model
Velké monorepo by nemělo po každé změně spouštět všechny testy a buildy. Nx `affected` používá historii Git a graf projektů k výpočtu minimální množiny zasažených projektů a vynechává nesouvisející práci. [4]
Vzdálená cache sdílí hotové výsledky mezi vývojáři a CI, distribuované vykonávání pak rozděluje zbývající úlohy mezi více strojů. Bazel řeší stejnou třídu problému pomocí remote execution a cache pro build a test akce. [5][7][8]
CI v multirepu: menší rozsah neznamená nulovou koordinaci
V multirepu vidí jednotlivý pipeline přirozeně méně kódu, takže build a testy lze snáze omezit na jeden projekt. Je to skutečná výhoda u volně provázaných služeb s jasným vlastnictvím.
Náklady se projeví u závislostí mezi repozitáři. Změna společné knihovny nebo kontraktu může vyžadovat publikaci, aktualizace více repozitářů, řešení kompatibility verzí a integrační testy. Google uvádí stabilitu jako výhodu multirepa a viditelnost a migrace jako silné stránky monorepa. [1]
Architektonické hranice: monorepo bez pravidel se rychle stane problémem
Společný repozitář nemá znamenat volné importy mezi všemi projekty. Nx může deklarativně vynucovat hranice modulů pomocí tagů a omezení závislostí a blokovat nechtěné importy a neplánované provázání. [6]
V multirepu některé hranice existují fyzicky díky samostatným repozitářům. Architekturu to ale nenahrazuje: silné vazby mohou vznikat přes API, databáze, fronty nebo sdílené knihovny.
Přístup a bezpečnost: multirepo má často jednodušší model
GitHub přiděluje role a oprávnění na úrovni repozitáře. Samostatné repozitáře proto přirozeně vyhovují situacím, kdy různé týmy nebo dodavatelé mají vidět různé části kódu. Role sahají od Read po Admin. [11]
V monorepu mohou CODEOWNERS a rulesets vynucovat review pro konkrétní cesty a týmy, ale jde o mechanismy vlastnictví a schvalování. Pokud je potřeba tvrdě oddělit viditelnost kódu, samostatné privátní repozitáře obvykle odpovídají přístupovému modelu přímočařeji. [10][12]
Releasy a nasazení: jeden repozitář neznamená jeden release
Yarn popisuje workspaces jako více balíčků v jednom projektu a výslovně uvádí, že mohou být nasazovány nezávisle. Gradle multi-project builds také rozdělují systém na logické subprojekty s vlastními závislostmi a úlohami. [13][15]
Monorepo tedy může mít samostatné pipeline a verze pro aplikace, služby i knihovny. Multirepo nabízí tuto nezávislost přirozeněji, ale potřebuje více automatizace, když se má více releasů koordinovat jako jedna produktová změna.
Velikost repozitáře a Git: velmi velká monorepa vyžadují cílené nástroje
Google popsal interní monorepo s miliardami řádků kódu, zároveň však zdůraznil vlastní infrastrukturu, která ho podporuje. Příklad dokazuje, že monorepo může škálovat velmi daleko, ne že je taková škála zdarma nebo vhodná pro každou firmu. [2]
Aktuální Git nabízí `sparse-checkout`, který omezuje working tree na vybranou podmnožinu sledovaných souborů. Je to užitečný nástroj pro velké repozitáře, i když dokumentace Git stále označuje jeho chování za experimentální a změnitelné. [9]
Nástroje v roce 2026 snižují náklady obou přístupů
V JavaScript ekosystému existují nativní workspaces a vyspělé nástroje pro grafy projektů, cache a affected-only CI. V JVM podporuje Gradle multi-project builds a composite builds umožňují spojit nezávislé buildy a vyvíjet je společně bez předchozí publikace artefaktů. [13][15][16]
To je důležité i pro multirepo: samostatné repozitáře nemusí znamenat úplně oddělený lokální vývoj. Composite builds ukazují, jak zachovat nezávislé hranice a přitom projekty testovat společně. [16]
AI coding agents přidávají v roce 2026 nové kritérium
Dokumentace Nx z roku 2026 tvrdí, že coding agents těží z úplného kontextu monorepa, dotazovatelného grafu projektů, rychlé affected-only kontroly a vynucených hranic. Protože Nx dodává monorepo tooling, je to produktový pohled, ne nezávislý důkaz. [3]
V praxi může sdílený kontext agentovi pomoci změnit kontrakt i jeho konzumenty v jedné úloze. Multirepo naopak může omezit množství kódu a oprávnění dostupných v jedné relaci agenta. Jde o další kritérium, ne samostatně rozhodující argument.
Kdy zvolit monorepo
Monorepo dává zvlášť smysl, když se aplikace a knihovny často mění společně, mnoho týmů sdílí komponenty a organizace potřebuje atomické refaktoringy a viditelný graf závislostí. Výzkum Google tyto výhody podporuje přes viditelnost, hledání API, příklady, migrace a centralizaci závislostí. [1]
Podmínkou je investice do hranic modulů, selektivního CI, cache, vlastnictví kódu a automatizace. Bez těchto kontrol růst pouze přesune složitost do jednoho obrovského pipeline. [4][5][6]
- Časté změny přes frontend, backend a knihovny.
- Hodně sdíleného kódu a společných standardů.
- Potřeba atomických refaktoringů.
- Jednotný nebo kompatibilní toolchain.
- Ochota investovat do grafu, cache a selektivního CI.
- Žádný tvrdý požadavek skrývat většinu kódu před dalšími interními týmy.
Kdy zvolit multirepo
Multirepo je silná volba, když mají domény jasné hranice, týmy potřebují nezávislé toolchainy, životní cykly a oprávnění a průřezové změny jsou relativně vzácné. Google uvádí flexibilitu nástrojů, řízení přístupu a stabilitu jako významné výhody. [1]
Dalším signálem je omezená viditelnost kódu, oddělené compliance požadavky nebo různé skupiny dodavatelů. Model rolí GitHubu na úrovni repozitáře takové oddělení přímo podporuje. [11]
- Silná autonomie týmů a samostatné životní cykly.
- Různé jazyky, toolchainy a build procesy.
- Přísné požadavky na přístup nebo compliance.
- Málo změn přes více projektů.
- Stabilní kontrakty a vyspělá správa verzí.
- Nezávislé pipeline jsou důležitější než jeden graf celé platformy.
Hybridní model a praktické rozhodnutí v roce 2026
| Situace | Výchozí směr | Proč |
|---|---|---|
| Časté změny přes více aplikací a knihoven | Monorepo | Atomické refaktoringy a společný graf |
| Týmy nemají vidět všechen kód | Multirepo | Oprávnění repozitáře zjednodušují izolaci |
| Týmy potřebují různé toolchainy a životní cykly | Multirepo | Méně centrální standardizace |
| Silně sdílená platforma a knihovny | Monorepo | Lepší viditelnost a centralizace |
| Mnoho malých služeb | Záleží | Důležitější je četnost společných změn než počet služeb |
| Smíšené požadavky na domény, přístup a technologie | Hybrid | Doménová monorepa plus vybrané samostatné repozitáře |
Volba nemusí být binární. Organizace může mít doménová monorepa pro úzce související produkty, samostatné repozitáře pro bezpečnostně citlivé nebo klientské části a sdílené balíčky přes registry. Gradle composite builds dokonce ukazují technický model společného vývoje nezávislých buildů. [16]
Před migrací změřte četnost průřezových změn, počet sdílených závislostí, dobu CI, počet repozitářů dotčených typickou funkcí, požadavky na přístup a náklady na koordinaci releasů. Tato data by měla rozhodnout o topologii.
