Монорепозиторий vs мультирепозиторий: когда объединять проекты в один и как это влияет на скорость разработки

Вы запускаете новый проект. Создаёте репозиторий для фронтенда. Потом для бэкенда. Потом для мобилки. Через полгода у вас 15 репозиториев и хаос: нужно обновить общую библиотеку — обходите каждый репозиторий вручную. Хотите сделать атомарное изменение через фронт и бэк — два PR два ревью две синхронизации.

Знакомо? Это классическая проблема мультирепозиториев (polyrepo).

Альтернатива: монорепозиторий (monorepo) — один репозиторий для всего кода. Google Facebook Microsoft так работают. Но это не серебряная пуля.

Цифры которые имеют значение:

• Полная сборка в monorepo: на 15% медленнее из-за большего объёма

• Инкрементальная сборка в monorepo: до 40% быстрее благодаря оптимизированным зависимостям

• Установка зависимостей в polyrepo: в 3 раза дольше из-за повторений

• Обновление общих библиотек в monorepo: автоматически триггерит пересборку

• Обновление в polyrepo: вручную синхронизация через десятки репозиториев

• Google: монорепозиторий 80+ ТБ тысячи разработчиков ежедневно

• Facebook Amazon Netflix используют разные подходы под свои задачи

В статье: что такое monorepo и polyrepo как они влияют на скорость разработки когда выбирать каждый подход инструменты 2026 года опыт российских компаний практическое руководство по выбору миграция между подходами.

1. Определения: что такое mono и polyrepo

Монорепозиторий (Monorepo)

Определение: единый репозиторий содержащий код множества проектов пакетов библиотек сервисов приложений.

Структура типичного монорепозитория:

my-monorepo/
├── packages/
│   ├── web-app/          # React приложение
│   ├── mobile-app/       # React Native
│   ├── backend-api/      # Node.js API
│   ├── admin-panel/      # Admin интерфейс
│   └── shared-ui/        # Общие компоненты
├── libs/
│   ├── auth/             # Библиотека авторизации
│   ├── utils/            # Утилиты
│   └── types/            # TypeScript типы
├── tools/                # Инструменты сборки
├── .github/              # CI/CD конфигурация
└── package.json          # Корневой package.json

Ключевые характеристики:

• Все проекты в одном репозитории

• Общие зависимости

• Единая система сборки

• Атомарные коммиты через проекты

• Централизованное управление

Мультирепозиторий (Polyrepo / Multi-repo)

Определение: каждый проект сервис библиотека живёт в отдельном репозитории.

Структура:

Организация на GitHub:
├── company/web-app              # Отдельный репозиторий
├── company/mobile-app           # Отдельный репозиторий
├── company/backend-api          # Отдельный репозиторий
├── company/admin-panel          # Отдельный репозиторий
└── company/shared-ui            # Отдельный репозиторий (npm пакет)

Ключевые характеристики:

• Каждый проект — отдельный репозиторий

• Независимые зависимости

• Отдельные CI/CD пайплайны

• Связь через пакетные менеджеры (npm yarn)

• Децентрализованное управление

Ключевые различия

2. Влияние на скорость разработки: конкретные цифры

Метрики которые измеряли

Исследование сравнивающее monorepo и polyrepo на реальных проектах показало:

1. Время сборки

Почему так:

• Полная сборка медленнее в monorepo: больше кода загружается единовременно

• Инкрементальная быстрее в monorepo: инструменты знают все зависимости пересобирают только нужное

• Зависимости быстрее в monorepo: устанавливаются один раз а не для каждого проекта

2. Время на координацию изменений

Сценарий: нужно изменить общую библиотеку используемую в 5 проектах.

Экономия времени в monorepo: 4-8x на кросс-проектных изменениях.

3. Скорость онбординга новых разработчиков

4. Частота деплоев

Наблюдения из индустрии:

• Amazon (polyrepo): тысячи деплоев в день независимые команды

• Google (monorepo): тысячи изменений в день централизованный контроль качества

Вывод: скорость деплоев зависит не от структуры репозитория а от культуры и процессов.

Реальный кейс: переход на monorepo

Компания: Средний SaaS стартап 30 разработчиков

До (polyrepo):

• 12 репозиториев

• Обновление общей библиотеки: 2-3 дня на все проекты

• Новый разработчик: 1 неделя на настройку

• Несовместимости версий: регулярно

После (monorepo с Nx):

• 1 репозиторий

• Обновление общей библиотеки: 1 PR все проекты обновляются атомарно

• Новый разработчик: 1-2 дня

• Несовместимости версий: исчезли

• CI время: сократилось на 30% благодаря кэшированию

ROI: экономия 20-25 часов в неделю на всю команду

3. Когда выбирать монорепозиторий

Сильные сигналы для monorepo

1. Тесная связанность проектов

• Фронтенд и бэкенд используют общие типы данных (TypeScript)

• Изменения часто затрагивают несколько проектов одновременно

• Много общих библиотек и компонентов

Пример: веб-приложение мобильное приложение админка — все на одном стеке (React/React Native) используют общие UI компоненты бизнес-логику типы.

2. Команда работает кросс-функционально

• Разработчики работают над фичами а не над проектами

• Одна фича может затрагивать фронт бэк мобилку

• Нет чётких границ «команда фронтенда» «команда бэкенда»

3. Важна консистентность

• Единый code style

• Одинаковые версии зависимостей

• Общие инструменты разработки

• Централизованный контроль качества

4. Частые рефакторинги

• Активное развитие продукта

• Регулярные изменения API

• Необходимость видеть влияние изменений сразу

5. Средний размер команды (10-100 человек)

• Достаточно большая чтобы иметь несколько проектов

• Достаточно маленькая чтобы управлять monorepo

• Все знают друг друга сотрудничают

Примеры компаний использующих monorepo

Российские компании:

• Gaijin Entertainment: monorepo для игровых проектов

• Некоторые команды в Яндексе: внутренние монорепозитории

4. Когда выбирать мультирепозиторий

Сильные сигналы для polyrepo

1. Независимые продукты или сервисы

• Микросервисная архитектура со слабой связанностью

• Каждый сервис можно разрабатывать деплоить независимо

• Разные команды разные технологии

Пример: маркетплейс где каждый микросервис (каталог корзина платежи уведомления) — отдельная команда на своём стеке.

2. Разные циклы релизов

• Один проект выпускается раз в месяц

• Другой — 10 раз в день

• Разные требования к стабильности

3. Независимые команды с разной культурой

• Команды в разных офисах/странах

• Разные процессы code review

• Разные инструменты и практики

• Не хотят согласовывать стандарты

4. Нужны строгие границы доступа

• Конфиденциальные проекты

• Разные уровни доступа для разработчиков

• Работа с контракторами

5. Очень большая организация (сотни команд)

• Monorepo становится узким местом

• Слишком много конфликтов

• Невозможно договориться о стандартах

Примеры компаний использующих polyrepo

Российские компании:

• inDriver: polyrepo для независимых сервисов

• True Engineering: шаблоны микросервисов в отдельных репо

5. Инструменты для монорепозиториев в 2026

Топ-5 инструментов

1. Nx (для JavaScript/TypeScript проектов)

Что делает:

• Интеллектуальная сборка (только изменённые проекты)

• Распределённое кэширование

• Граф зависимостей

• Генераторы кода

Подходит для: React Angular Node.js проекты frontend-heavy команды

Пример использования:

# Установка
npx create-nx-workspace@latest

# Сборка только изменённых проектов
nx affected:build

# Тест только затронутых проектов
nx affected:test

# Визуализация зависимостей
nx graph

2. Turborepo

Что делает:

• Параллельное выполнение задач

• Умное кэширование

• Инкрементальные сборки

• Удалённое кэширование (Vercel)

Подходит для: Next.js проекты современные JS/TS стеки

Особенность: проще чем Nx легче начать быстрое время настройки

3. Bazel (для enterprise и polyglot проектов)

Что делает:

• Поддержка множества языков (Java C++ Go Python JS)

• Детерминированные сборки

• Масштабируется до очень больших проектов

• Incremental builds на основе content hashing

Подходит для: очень большие проекты (Google-scale) мультиязычные кодовые базы

Недостаток: сложная настройка крутая кривая обучения

4. Lerna (для npm пакетов)

Что делает:

• Управление версиями пакетов

• Публикация в npm

• Выполнение команд через пакеты

Подходит для: библиотеки npm пакеты которые публикуются

Статус 2026: активно поддерживается но многие мигрируют на Nx/Turborepo

5. Rush (для крупного энтерпрайза)

Что делает:

• Строгое управление зависимостями

• Настраиваемые политики

• Incremental builds

• Подходит для больших корпораций

Используется: Microsoft внутренние проекты

Сравнительная таблица

6. Типичные проблемы и решения

Проблемы монорепозитория

Проблема 1: Медленный Git

Симптомы: git status выполняется 10+ секунд клонирование занимает часы.

Решения:

• Partial clone: git clone --filter=blob:none — загружает только нужные файлы

• Sparse checkout: работа только с нужными папками

• Git LFS: для больших бинарных файлов

• Shallow clone: git clone --depth 1 для CI

Проблема 2: Долгий CI/CD

Симптомы: каждый коммит запускает сборку всего репозитория 30+ минут.

Решения:

• Affected testing: тестируем только затронутые проекты

• Кэширование: переиспользуем результаты предыдущих сборок

• Параллелизация: запускаем независимые сборки параллельно

• Инкрементальная сборка: пересобираем только изменённое

Пример с Nx:

# Вместо полной сборки всего
nx run-many --target=build --all

# Собираем только изменённое
nx affected:build --base=origin/main

Экономия времени: с 30 минут до 3-5 минут на типичном PR.

Проблема 3: Конфликты при слиянии

Симптомы: частые конфликты потому что все работают в одном репо.

Решения:

• Trunk-based development: маленькие частые коммиты в main

• Feature flags: незавершённый код за флагами

• Code owners: правила кто может менять какой код

• Automated merging: боты автоматически мержат простые PR

Проблема 4: Связанность кода (tight coupling)

Симптомы: проекты начинают зависеть друг от друга напрямую нарушая границы.

Решения:

• Dependency constraints: правила какие проекты могут зависеть друг от друга

• Module boundaries: автоматическая проверка нарушений архитектуры

• Папка internal: код который не должен использоваться вне проекта

Nx: настройка границ модулей

// nx.json или .eslintrc
{
  "nx": {
    "tags": ["scope:web", "scope:mobile", "scope:shared"],
    "enforce": [
      {
        "source": "scope:web",
        "onlyDependOnLibsWithTags": ["scope:web", "scope:shared"]
      },
      {
        "source": "scope:mobile",
        "onlyDependOnLibsWithTags": ["scope:mobile", "scope:shared"]
      }
    ]
  }
}

Теперь веб не может импортить код из мобильного приложения.

Проблемы мультирепозитория

Проблема 1: Рассинхронизация версий

Симптомы: один проект использует библиотеку v1.2 другой v2.0 третий v1.5 — несовместимости.

Решения:

• Renovate / Dependabot: автоматические PR на обновление зависимостей

• Семантическое версионирование: строгое следование SemVer

• Lockfiles: фиксируют точные версии

• Монорепозиторий для shared библиотек: гибридный подход

Проблема 2: Дублирование кода

Симптомы: один и тот же код скопирован в 5 репозиториев.

Решения:

• Выделить в npm пакет: опубликовать переиспользовать

• Git submodules: (не рекомендуется сложно поддерживать)

• Монорепозиторий для общего кода: часть проектов в polyrepo часть в monorepo

Проблема 3: Координация изменений

Симптомы: нужно изменить API бэкенда — требуются синхронизированные изменения в 3 фронтендах.

Решения:

• API versioning: старая и новая версии живут параллельно

• Backward compatibility: новые изменения не ломают старых клиентов

• Автоматизация: скрипты для создания PR во все репо одновременно

• Инструменты: Lyft Refactorator — автоматизирует изменения через множество репо

7. Миграция между подходами

Из polyrepo в monorepo

Когда имеет смысл:

• Проводите много времени на синхронизацию между репо

• Есть 5-15 тесно связанных проектов

• Команда готова инвестировать в инструменты

План миграции (6-8 недель):

1. Неделя 1-2: Подготовка

   • Выберите инструмент (Nx Turborepo)

   • Создайте пустой monorepo

   • Настройте структуру папок

   • Установите правила и процессы

2. Неделя 3-4: Перенос shared библиотек

   • Начните с общих пакетов

   • Настройте build system

   • Проверьте что всё собирается

3. Неделя 5-6: Перенос основных проектов

   • По одному проекту за раз

   • Обновите импорты с npm на локальные

   • Настройте CI для каждого проекта

4. Неделя 7-8: Оптимизация и обучение

   • Настройте affected testing

   • Включите кэширование

   • Обучите команду новым процессам

   • Документируйте workflow

Критические ошибки при миграции:

• Переносить всё сразу — делайте инкрементально

• Не настроить CI правильно — сборка будет долгой

• Не обучить команду — будет сопротивление

• Не установить правила — код станет спагетти

Из monorepo в polyrepo

Когда имеет смысл:

• Monorepo стал слишком большим (500+ разработчиков)

• Проекты реально независимы

• Разные команды хотят автономии

• Git стал узким местом

План миграции:

1. Идентифицируйте границы: какие проекты можно выделить

2. Определите зависимости: что нужно опубликовать как пакеты

3. Создайте репо: по одному выделяя проекты

4. Настройте CI/CD: для каждого нового репо

5. Опубликуйте shared библиотеки: в npm или приватный registry

6. Обновите импорты: с локальных на npm пакеты

Внимание: это сложнее чем кажется часто приводит к проблемам. Хорошо подумайте нужно ли.

8. Российский опыт и кейсы

Gaijin Entertainment (монорепозиторий)

Контекст: разработка игр (War Thunder и другие)

Почему monorepo:

• Игровой движок общий код ресурсы

• Тесная интеграция между компонентами

• Важна консистентность версий

• Культура совместной работы

Плюсы которые отмечают:

• Удобная работа с общим кодом

• Легко поддерживать общие библиотеки

• Видна вся структура проекта

• Атомарные изменения через компоненты

inDriver (мультирепозиторий)

Контекст: такси-сервис микросервисная архитектура

Почему polyrepo:

• Десятки независимых микросервисов

• Разные команды разные стеки

• Нужна автономия команд

• Разные циклы деплоя

Как управляют:

• Шаблоны для новых сервисов

• Centralized платформа для CI/CD

• Service mesh для координации

True Engineering (гибридный подход)

Решение:

• Monorepo: для фронтенд приложений и shared UI библиотек

• Polyrepo: для бэкенд микросервисов

Почему работает:

• Фронтенд компоненты тесно связаны — выигрыш от monorepo

• Микросервисы независимы — polyrepo даёт автономию

• Шаблоны микросервисов ускоряют создание новых

9. Гибридные подходы

Концепция: не нужно выбирать всё или ничего. Можно комбинировать.

Паттерн 1: Multiple Monorepos

Структура:

• Monorepo #1: Frontend (веб мобилка админка shared UI)

• Monorepo #2: Backend сервисы которые часто меняются вместе

• Polyrepo: Стабильные legacy сервисы

Когда использовать: разные части системы имеют разную степень связанности.

Паттерн 2: Monorepo + Published Packages

Структура:

• Внутри monorepo разрабатываете всё

• Стабильные библиотеки публикуете в npm

• Внешние проекты используют npm пакеты

Пример:

my-monorepo/
├── apps/                    # Приложения
│   ├── web/
│   └── mobile/
├── libs/                    # Внутренние библиотеки
│   ├── ui-components/       # Публикуется в npm
│   ├── utils/               # Публикуется в npm
│   └── internal/            # Только внутреннее использование

Паттерн 3: Shared Libraries Monorepo

Структура:

• Общие библиотеки в monorepo

• Приложения в отдельных репо

• Приложения зависят от опубликованных пакетов из monorepo

Преимущество: избегаете дублирования но сохраняете автономию приложений.

10. Практическое руководство: как выбрать

Фреймворк принятия решения

Шаг 1: Оцените по чек-листу

Шаг 2: Посчитайте баллы

• Умножьте каждый балл на вес (высокий=2 средний=1 низкий=0.5)

• Суммируйте для monorepo и polyrepo

• Что больше — то и выбирайте

Матрица принятия решений

Быстрые вопросы для самопроверки

Выбирайте Monorepo если:

• ✅ Изменения часто затрагивают 2+ проекта одновременно

• ✅ Проекты на одном стеке (TypeScript React Node)

• ✅ Команда 10-100 человек все сотрудничают

• ✅ Готовы вложиться в Nx Turborepo Bazel

• ✅ Важна скорость разработки а не автономия

Выбирайте Polyrepo если:

• ✅ Проекты действительно независимы (микросервисы)

• ✅ Разные команды разные стеки разные процессы

• ✅ Нужны строгие границы доступа

• ✅ Команды хотят автономии

• ✅ Проекты деплоятся независимо с разной частотой

Рассмотрите гибрид если:

• ✅ Часть проектов связана часть независима

• ✅ Хотите преимущества обоих подходов

• ✅ Готовы к чуть большей сложности

11. Заключение: главные выводы

Не существует универсального ответа. Mono и polyrepo — это компромиссы с разными trade-offs.

Ключевые принципы:

1. Решение зависит от контекста

   • Размер команды

   • Связанность проектов

   • Культура разработки

   • Готовность инвестировать в инструменты

2. Monorepo ≠ быстрее автоматически

   • Без правильных инструментов будет медленнее

   • Нужны Nx Turborepo Bazel кэширование

   • Нужна дисциплина и процессы

3. Polyrepo ≠ хаос автоматически

   • С правильной автоматизацией работает отлично

   • Amazon Netflix показывают что это scale

   • Нужны инструменты для координации

4. Гибридные подходы валидны

   • Не обязательно всё или ничего

   • Multiple monorepos часто оптимальны

   • Комбинируйте под свои нужды

5. Миграция возможна но болезненна

   • Не меняйте без веской причины

   • Если меняете делайте инкрементально

   • Инвестируйте в обучение команды

Влияние на скорость разработки:

Практические рекомендации на 2026:

• Малые команды (до 10 человек): начните с простого polyrepo переходите на monorepo только если явные боли

• Средние команды (10-50): если проекты связаны — monorepo с Nx или Turborepo окупится

• Большие команды (50+): скорее всего нужен гибридный подход или multiple monorepos

• Enterprise (100+): инвестируйте в специализированные инструменты (Bazel Rush) или строгую платформу для polyrepo

Последняя мысль: структура репозиториев это не техническая проблема а организационная. Выбор между mono и polyrepo отражает как ваша команда хочет работать. Google выбрала monorepo потому что ценит тесную интеграцию и контроль качества. Amazon выбрала polyrepo потому что ценит автономию команд и скорость независимых деплоев. Оба подхода работают в масштабе.

Ваш выбор должен отражать ваши ценности: сотрудничество vs автономия консистентность vs гибкость скорость разработки vs скорость деплоя.

Не копируйте слепо Google или Amazon. Поймите что важно для вашей команды начните с простого измеряйте эволюционируйте.

И помните: правильные инструменты и процессы важнее чем структура репозиториев. Плохой monorepo хуже хорошего polyrepo. И наоборот.

А лучшие вакансии для разработчиков ищите на hirehi.ru