Монорепозиторий: много проектов в одном репозитории

Коротко: Несколько связанных программ и библиотек живут вместе в одном репозитории 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, Модульный монолит