Monorepo a multirepo: definície bez chybných skratiek
| Kritérium | Monorepo | Multirepo |
|---|---|---|
| Priečne zmeny | Jeden commit alebo PR môže pokryť viac projektov | Zvyčajne viac repozitárov, verzií a PR |
| Závislosti | Jednoduchšia centralizácia a spoločné pravidlá | Väčšia nezávislosť verzií |
| CI | Vyžaduje výber podľa grafu, cache a škálovanie | Menší prirodzený rozsah pipeline |
| Prístup | Vlastníctvo ciest cez pravidlá a review | Prirodzená izolácia na úrovni repozitára |
| Nástroje | Viac spoločných štandardov | Viac slobody pre projekt |
| Releasy | Môžu byť nezávislé, potrebujú orchestráciu | Prirodzene oddelené pipeline |
Monorepo je jeden repozitár obsahujúci viac logicky oddelených projektov, napríklad aplikácie, služby, knižnice alebo nástroje. Multirepo, nazývané aj polyrepo, drží tieto časti v samostatných repozitároch. Hranice repozitára sú hranice správy zdrojového kódu, nie automaticky hranice nasadenia. [1][13][15]
Monorepo teda môže obsahovať mnoho nezávisle nasadzovaných služieb, zatiaľ čo multirepo môže obsahovať moduly jedného veľkého systému. Zamieňať stratégiu repozitárov s monolitom alebo mikroslužbami vedie k zlým architektonickým rozhodnutiam.
Čo ukazuje výskum Google: oba modely majú reálne výhody
Google Research medzi inžiniermi so skúsenosťou s oboma modelmi označil viditeľnosť celej codebase za významnú výhodu monorepa. Pomáha hľadať znovupoužiteľné API, príklady použitia a aktualizovať závislý kód pri migráciách. Oceňované bolo aj centralizované riadenie závislostí. [1]
Rovnaká štúdia uvádza výhody multirepa: väčšiu voľnosť toolchainov, silnejšie hranice prístupu a väčšiu stabilitu medzi projektmi. Autori tiež zdôrazňujú význam kvality nástrojov okolo zvoleného modelu. [1]
Priečne zmeny: najjasnejšia praktická výhoda monorepa
Keď jedna zmena rozhrania vyžaduje súčasne upraviť backend, frontend, knižnice a testy, monorepo môže celú migráciu obsahovať v jednom commite alebo pull requeste. Google uvádza aktualizáciu závislého kódu pri migráciách API ako dôležitý prínos spoločného repozitára. [1][2]
V multirepe sa rovnaká zmena často zmení na sled krokov: upraviť producenta, vydať verziu, aktualizovať konzumentov a koordinovať viac pull requestov. Automatizácia pomáha, ale hranice repozitárov zostávajú hranicami integračného procesu.
Závislosti a verzie: centralizácia proti nezávislosti
Monorepo uľahčuje zjednotenie spoločných verzií závislostí a priame odkazy medzi lokálnymi balíkmi. Yarn Workspaces prepája balíky v jednom projekte a Constraints môže v celom workspace vynucovať pravidlá verzií alebo `package.json`. [13][14]
Multirepo dáva jednotlivým projektom väčšiu slobodu vo verziách a načasovaní aktualizácií, ale spoločné knižnice sa môžu medzi repozitármi rozchádzať. Funguje dobre so stabilnými kontraktmi a riadeným publikovaním artefaktov.
CI v monorepe: prebudovať všetko pri každom commite je zlý model
Veľké monorepo by nemalo po každej zmene spúšťať všetky testy a buildy. Nx `affected` používa históriu Git a graf projektov na výpočet minimálnej množiny zasiahnutých projektov a vynecháva nesúvisiacu prácu. [4]
Vzdialená cache zdieľa hotové výsledky medzi vývojármi a CI, distribuované vykonávanie potom rozdeľuje zostávajúce úlohy medzi viac strojov. Bazel rieši rovnakú triedu problému pomocou remote execution a cache pre build a test akcie. [5][7][8]
CI v multirepe: menší rozsah neznamená nulovú koordináciu
V multirepe vidí jeden pipeline prirodzene menej kódu, takže build a testy možno jednoduchšie obmedziť na jeden projekt. Je to reálna výhoda pri voľne previazaných službách s jasným vlastníctvom.
Náklady sa objavia pri závislostiach medzi repozitármi. Zmena spoločnej knižnice alebo kontraktu môže vyžadovať publikovanie, aktualizácie viacerých repozitárov, kompatibilitu verzií a integračné testy. Google uvádza stabilitu ako výhodu multirepa a viditeľnosť a migrácie ako silné stránky monorepa. [1]
Architektonické hranice: monorepo bez pravidiel sa rýchlo stane problémom
Spoločný repozitár nemá znamenať voľné importy medzi všetkými projektmi. Nx môže deklaratívne vynucovať hranice modulov pomocou tagov a obmedzení závislostí a blokovať nechcené importy a neplánované previazanosti. [6]
V multirepe niektoré hranice existujú fyzicky vďaka samostatným repozitárom. Architektúru to však nenahrádza: silné väzby môžu vzniknúť cez API, databázy, fronty alebo zdieľané knižnice.
Prístup a bezpečnosť: multirepo má často jednoduchší model
GitHub prideľuje roly a oprávnenia na úrovni repozitára. Samostatné repozitáre preto prirodzene vyhovujú situáciám, keď rôzne tímy alebo dodávatelia majú vidieť rôzne časti kódu. Roly siahajú od Read po Admin. [11]
V monorepe môžu CODEOWNERS a rulesets vynucovať review pre konkrétne cesty a tímy, ale ide o mechanizmy vlastníctva a schvaľovania. Ak je potrebné tvrdo oddeliť viditeľnosť kódu, samostatné privátne repozitáre zvyčajne zodpovedajú prístupovému modelu priamočiarejšie. [10][12]
Releasy a nasadenie: jeden repozitár neznamená jeden release
Yarn opisuje workspaces ako viac balíkov v jednom projekte a výslovne uvádza, že môžu byť nasadzované nezávisle. Gradle multi-project builds tiež rozdeľujú systém na logické subprojekty s vlastnými závislosťami a úlohami. [13][15]
Monorepo teda môže mať samostatné pipeline a verzie pre aplikácie, služby aj knižnice. Multirepo ponúka túto nezávislosť prirodzenejšie, ale potrebuje viac automatizácie, keď sa má viac releasov koordinovať ako jedna produktová zmena.
Veľkosť repozitára a Git: veľmi veľké monorepá vyžadujú cielené nástroje
Google opísal interné monorepo s miliardami riadkov kódu, zároveň však zdôraznil vlastnú infraštruktúru, ktorá ho podporuje. Príklad dokazuje, že monorepo môže škálovať veľmi ďaleko, nie že je taká škála zadarmo alebo vhodná pre každú firmu. [2]
Aktuálny Git ponúka `sparse-checkout`, ktorý obmedzuje working tree na vybranú podmnožinu sledovaných súborov. Je to užitočný nástroj pre veľké repozitáre, aj keď dokumentácia Git stále označuje jeho správanie za experimentálne a zmeniteľné. [9]
Nástroje v roku 2026 znižujú náklady oboch prístupov
V JavaScript ekosystéme existujú natívne workspaces a vyspelé nástroje pre grafy projektov, cache a affected-only CI. V JVM podporuje Gradle multi-project builds a composite builds umožňujú spojiť nezávislé buildy a vyvíjať ich spoločne bez predchádzajúceho publikovania artefaktov. [13][15][16]
To je dôležité aj pre multirepo: samostatné repozitáre nemusia znamenať úplne oddelený lokálny vývoj. Composite builds ukazujú, ako zachovať nezávislé hranice a pritom projekty testovať spoločne. [16]
AI coding agents pridávajú v roku 2026 nové kritérium
Dokumentácia Nx z roku 2026 tvrdí, že coding agents ťažia z úplného kontextu monorepa, dotazovateľného grafu projektov, rýchlej affected-only kontroly a vynucovaných hraníc. Keďže Nx dodáva monorepo tooling, ide o produktový pohľad, nie nezávislý dôkaz. [3]
V praxi môže spoločný kontext agentovi pomôcť zmeniť kontrakt aj jeho konzumentov v jednej úlohe. Multirepo naopak môže obmedziť množstvo kódu a oprávnení dostupných v jednej relácii agenta. Ide o ďalšie kritérium, nie samostatne rozhodujúci argument.
Kedy zvoliť monorepo
Monorepo dáva zvlášť zmysel, keď sa aplikácie a knižnice často menia spoločne, veľa tímov zdieľa komponenty a organizácia potrebuje atomické refaktoringy a viditeľný graf závislostí. Výskum Google tieto výhody podporuje cez viditeľnosť, hľadanie API, príklady, migrácie a centralizáciu závislostí. [1]
Podmienkou je investícia do hraníc modulov, selektívneho CI, cache, vlastníctva kódu a automatizácie. Bez týchto kontrol rast iba presunie zložitosť do jedného obrovského pipeline. [4][5][6]
- Časté zmeny cez frontend, backend a knižnice.
- Veľa zdieľaného kódu a spoločných štandardov.
- Potreba atomických refaktoringov.
- Jednotný alebo kompatibilný toolchain.
- Ochota investovať do grafu, cache a selektívneho CI.
- Žiadna tvrdá požiadavka skrývať väčšinu kódu pred ďalšími internými tímami.
Kedy zvoliť multirepo
Multirepo je silná voľba, keď majú domény jasné hranice, tímy potrebujú nezávislé toolchainy, životné cykly a oprávnenia a priečne zmeny sú relatívne zriedkavé. Google uvádza flexibilitu nástrojov, riadenie prístupu a stabilitu ako významné výhody. [1]
Ďalším signálom je obmedzená viditeľnosť kódu, oddelené compliance požiadavky alebo rôzne skupiny dodávateľov. Model rolí GitHubu na úrovni repozitára takéto oddelenie priamo podporuje. [11]
- Silná autonómia tímov a samostatné životné cykly.
- Rôzne jazyky, toolchainy a build procesy.
- Prísne požiadavky na prístup alebo compliance.
- Málo zmien cez viac projektov.
- Stabilné kontrakty a vyspelá správa verzií.
- Nezávislé pipeline sú dôležitejšie než jeden graf celej platformy.
Hybridný model a praktické rozhodnutie v roku 2026
| Situácia | Predvolený smer | Prečo |
|---|---|---|
| Časté zmeny cez viac aplikácií a knižníc | Monorepo | Atomické refaktoringy a spoločný graf |
| Tímy nemajú vidieť všetok kód | Multirepo | Oprávnenia repozitára zjednodušujú izoláciu |
| Tímy potrebujú rôzne toolchainy a životné cykly | Multirepo | Menej centrálnej štandardizácie |
| Silno zdieľaná platforma a knižnice | Monorepo | Lepšia viditeľnosť a centralizácia |
| Veľa malých služieb | Závisí | Dôležitejšia je frekvencia spoločných zmien než počet služieb |
| Zmiešané požiadavky na domény, prístup a technológie | Hybrid | Doménové monorepá plus vybrané samostatné repozitáre |
Voľba nemusí byť binárna. Organizácia môže mať doménové monorepá pre úzko súvisiace produkty, samostatné repozitáre pre bezpečnostne citlivé alebo klientské časti a zdieľané balíky cez registry. Gradle composite builds dokonca ukazujú technický model spoločného vývoja nezávislých buildov. [16]
Pred migráciou zmerajte frekvenciu priečnych zmien, počet zdieľaných závislostí, čas CI, počet repozitárov dotknutých typickou funkciou, požiadavky na prístup a náklady na koordináciu releasov. Tieto dáta by mali rozhodnúť o topológii.
