Монорепозиторій: багато проєктів в одному репозиторії

Коротко: Кілька пов’язаних програм і бібліотек живуть разом в одному репозиторії Git замість безлічі окремих.

Докладніше: У монорепозиторії фронтенд, бекенд, спільні бібліотеки та інструменти ділять один репозиторій, але зазвичай мають свої теки й пакети. Так працюють великі компанії на кшталт Google чи Meta, а у світі JavaScript це поширено з інструментами на кшталт pnpm workspaces, Nx або Turborepo. Протилежність — полірепозиторій (polyrepo), у якому кожен проєкт має свій репозиторій.

Подробиці

Структура

my-company/
  apps/
    web/
    api/
  packages/
    ui/            спільні будівельні блоки
    config/
  package.json     конфігурація робочого простору

Пакети посилаються один на одного через локальні залежності, і одна команда встановлює все.

Переваги

• Атомарні зміни: зміну бібліотеки та всіх її користувачів можна зробити в одному коміті й pull request.
• Спільні інструменти: одне налаштування лінтингу й тестів, одна стратегія версіонування.
• Легке спільне використання коду без публікації пакетів.
• Огляд: усе в одному місці, легко шукати.

Недоліки та заходи

Репозиторій стає великим, а наївні конвеєри перезбирають усе за кожної зміни. Сучасні інструменти збирають лише зачеплене (граф залежностей) і використовують кеш збирання, зокрема й спільний для команди. Права доступу важче розділяти за проєктами; допомагають файли власників коду (CODEOWNERS). Дуже великим репозиторіям потрібні можливості Git на кшталт sparse checkout.

Ухвалення рішення

Для невеликої команди зі пов’язаними частинами монорепозиторій часто зручніший. Якщо проєкти незалежні, з окремими командами й циклами релізів, полірепозиторій може мати більше сенсу. Монорепозиторій — не те саме, що моноліт: сервіси й там можна збирати та постачати окремо.

Див. також: Git, Конвеєр CI/CD, SemVer, Модульний моноліт