Monorepo і multirepo: визначення без хибних ототожнень
| Критерій | Monorepo | Multirepo |
|---|---|---|
| Наскрізні зміни | Один commit або PR може охопити кілька проєктів | Зазвичай кілька репозиторіїв, версій і PR |
| Залежності | Простіша централізація та спільні правила | Більша незалежність версій |
| CI | Потребує вибору за графом, кешу та масштабування | Менший природний обсяг одного pipeline |
| Доступ | Ownership шляхів через правила та review | Природна ізоляція на рівні репозиторію |
| Інструменти | Більше спільних стандартів | Більше свободи для проєкту |
| Релізи | Можуть бути незалежними, потребують оркестрації | Природно окремі pipeline |
Monorepo це один репозиторій, який містить кілька логічно окремих проєктів, наприклад застосунки, сервіси, бібліотеки або інструменти. Multirepo, також polyrepo, зберігає ці частини в окремих репозиторіях. Межі репозиторію є межами керування вихідним кодом, а не автоматично межами deployment. [1][13][15]
Тому monorepo може містити багато незалежно розгорнутих сервісів, а multirepo може містити модулі одного великого продукту. Ототожнення стратегії репозиторіїв з монолітом або мікросервісами призводить до слабких архітектурних рішень.
Що показує дослідження Google: обидві моделі мають реальні переваги
Google Research серед інженерів з досвідом обох моделей назвав видимість усієї codebase важливою перевагою monorepo. Вона допомагає знаходити API для повторного використання, приклади та оновлювати залежний код під час міграцій. Також позитивно оцінювалася централізована робота із залежностями. [1]
Те саме дослідження називає переваги multirepo: більша свобода toolchain, сильніші межі доступу та вища стабільність між проєктами. Автори також підкреслюють, що якість інструментів навколо моделі має велике значення. [1]
Наскрізні зміни: найочевидніша практична перевага monorepo
Якщо одна зміна інтерфейсу потребує одночасного оновлення backend, frontend, бібліотек і тестів, monorepo дозволяє помістити всю міграцію в один commit або pull request. Google називає оновлення залежного коду під час міграцій API важливою перевагою спільного репозиторію. [1][2]
У multirepo така сама зміна часто стає послідовністю: змінити producer, випустити версію, оновити consumers і координувати кілька pull request. Автоматизація знижує тертя, але межі репозиторіїв залишаються межами інтеграційного процесу.
Залежності та версії: централізація проти незалежності
Monorepo спрощує вирівнювання спільних версій залежностей і прямі посилання між локальними пакетами. Yarn Workspaces пов'язує пакети в одному проєкті, а Constraints може примусово підтримувати правила версій або `package.json` у всьому workspace. [13][14]
Multirepo дає кожному проєкту більше свободи у версіях і часі оновлення, але спільні бібліотеки можуть розходитися між репозиторіями. Модель добре працює зі стабільними контрактами та контрольованою публікацією артефактів.
CI у monorepo: перебудовувати все після кожного commit це неправильна модель
Велике monorepo не повинно запускати всі тести та build після кожної зміни. Nx `affected` використовує історію Git і граф проєктів, щоб визначити мінімальний набір змінених проєктів і пропустити непов'язану роботу. [4]
Віддалений кеш ділиться готовими результатами між машинами розробників і CI, а розподілене виконання розносить решту задач між кількома машинами. Bazel вирішує той самий клас задач за допомогою remote execution і кешу для build та test actions. [5][7][8]
CI у multirepo: менший обсяг не означає нульову координацію
У multirepo окремий pipeline природно бачить менше коду, тому build і тести простіше обмежити одним проєктом. Це реальна перевага для слабо пов'язаних сервісів з чітким ownership.
Витрати з'являються через залежності між репозиторіями. Зміна спільної бібліотеки або контракту може вимагати публікації, оновлень кількох репозиторіїв, сумісності версій та інтеграційних тестів. Google називає стабільність перевагою multirepo, а видимість і міграції сильними сторонами monorepo. [1]
Архітектурні межі: monorepo без правил швидко стає проблемою
Спільний репозиторій не повинен означати вільні imports між усіма проєктами. Nx може декларативно примусово підтримувати межі модулів за допомогою tags і dependency constraints, блокуючи небажані imports і незаплановане зчеплення. [6]
У multirepo деякі межі існують фізично завдяки окремим репозиторіям. Це не замінює архітектуру: сильна залежність все одно може виникати через API, бази даних, черги або спільні бібліотеки.
Доступ і безпека: multirepo часто має простішу модель
GitHub надає ролі та права на рівні репозиторію. Окремі репозиторії тому природно підходять, коли різні команди або підрядники повинні бачити різні codebase. Ролі варіюються від Read до Admin. [11]
У monorepo CODEOWNERS і rulesets можуть вимагати review для конкретних шляхів і команд, але це механізми ownership та затвердження. Якщо потрібне жорстке розділення видимості коду, окремі приватні репозиторії зазвичай краще відповідають моделі доступу. [10][12]
Релізи та deployment: один репозиторій не означає один release
Yarn описує workspaces як кілька пакетів одного проєкту і прямо зазначає, що вони можуть deployment незалежно. Gradle multi-project builds також розділяють систему на логічні підпроєкти з власними залежностями та задачами. [13][15]
Отже, monorepo може мати окремі pipeline і версії для застосунків, сервісів і бібліотек. Multirepo дає цю незалежність природніше, але потребує більше автоматизації, коли кілька релізів треба координувати як одну зміну продукту.
Розмір репозиторію та Git: дуже великі monorepo потребують спеціальних інструментів
Google описав внутрішнє monorepo з мільярдами рядків коду, але водночас наголосив на спеціальній інфраструктурі. Приклад доводить, що monorepo може масштабуватися дуже далеко, а не те, що таке масштабування безкоштовне або підходить кожній компанії. [2]
Сучасний Git пропонує `sparse-checkout`, який обмежує working tree вибраною підмножиною tracked files. Це корисний інструмент для великих репозиторіїв, хоча документація Git досі називає його поведінку експериментальною та такою, що може змінюватися. [9]
Інструменти 2026 року зменшують вартість обох підходів
У JavaScript є native workspaces та зрілі інструменти для project graph, кешу й affected-only CI. У JVM Gradle підтримує multi-project builds, а composite builds дозволяють поєднувати незалежні build і розробляти їх разом без попередньої публікації артефактів. [13][15][16]
Це важливо і для multirepo: окремі репозиторії не обов'язково означають повністю роз'єднане локальне середовище. Composite builds показують, як зберігати незалежні межі та тестувати проєкти разом. [16]
AI coding agents додають новий критерій у 2026 році
Документація Nx 2026 року стверджує, що coding agents виграють від повного контексту monorepo, доступного project graph, швидкої affected-only перевірки та примусово заданих меж. Оскільки Nx є постачальником monorepo tooling, це слід сприймати як продуктову позицію, а не незалежний доказ. [3]
На практиці спільний контекст може допомогти агенту змінити контракт і його consumers в одній задачі. Multirepo натомість може обмежити обсяг коду й прав у межах однієї сесії агента. Це додатковий критерій, а не самостійний вирішальний аргумент.
Коли обирати monorepo
Monorepo особливо доречне, коли застосунки та бібліотеки часто змінюються разом, багато команд ділять компоненти, а організації потрібні атомарні refactorings і видимий граф залежностей. Дослідження Google підтримує ці переваги через видимість, пошук API, приклади, міграції та централізацію залежностей. [1]
Умова полягає в інвестиціях у межі модулів, вибірковий CI, кеш, ownership коду й автоматизацію. Без цих механізмів зростання лише переносить складність в один величезний pipeline. [4][5][6]
- Часті зміни через frontend, backend і бібліотеки.
- Багато спільного коду та стандартів.
- Потреба в атомарних refactorings.
- Єдиний або сумісний toolchain.
- Готовність інвестувати в graph, cache і selective CI.
- Немає жорсткої вимоги приховувати більшу частину коду від інших внутрішніх команд.
Коли обирати multirepo
Multirepo є сильним вибором, коли домени мають чіткі межі, командам потрібні незалежні toolchain, життєві цикли та права, а наскрізні зміни трапляються відносно рідко. Google називає гнучкість інструментів, контроль доступу та стабільність значущими перевагами. [1]
Ще один сигнал це код з обмеженою видимістю, окремі compliance-вимоги або різні групи підрядників. Репозиторна модель ролей GitHub безпосередньо підтримує таке розділення. [11]
- Висока автономія команд і окремі життєві цикли.
- Різні мови, toolchain і build-процеси.
- Суворі вимоги доступу або compliance.
- Рідкі зміни через багато проєктів.
- Стабільні контракти та зріле керування версіями.
- Незалежні pipeline важливіші за один граф усієї платформи.
Гібридна модель і практичне рішення у 2026 році
| Ситуація | Типовий напрям | Чому |
|---|---|---|
| Часті зміни через кілька застосунків і бібліотек | Monorepo | Атомарні refactorings і спільний граф |
| Команди не повинні бачити весь код | Multirepo | Права репозиторію спрощують ізоляцію |
| Командам потрібні різні toolchain і життєві цикли | Multirepo | Менше централізованої стандартизації |
| Сильно спільна платформа та бібліотеки | Monorepo | Краща видимість і централізація |
| Багато малих сервісів | Залежить | Частота спільних змін важливіша за кількість сервісів |
| Змішані вимоги доменів, доступу та технологій | Гібрид | Доменні monorepo плюс вибрані окремі репозиторії |
Вибір не обов'язково має бути бінарним. Організація може мати доменні monorepo для тісно пов'язаних продуктів, окремі репозиторії для security-sensitive або клієнтських частин і спільні пакети через registry. Gradle composite builds навіть показують технічну модель спільної розробки незалежних build. [16]
Перед міграцією варто виміряти частоту наскрізних змін, кількість спільних залежностей, час CI, кількість репозиторіїв, яких торкається типова функція, вимоги доступу та вартість координації релізів. Саме ці дані мають визначати топологію.
