Монорепозиторий

Монорепозиторий (от англ. monorepository, monorepo) — это подход к управлению исходным кодом, при котором код нескольких проектов, библиотек, сервисов или компонентов хранится в одном репозитории системы контроля версий (например, Git). В отличие от мультирепозиторной (полирепозиторной) стратегии, где каждый проект имеет собственный репозиторий, монорепозиторий объединяет все связанные артефакты разработки в единое хранилище. Данный подход активно используется в крупных технологических компаниях, таких как Google, Meta (организация признана экстремистской и запрещена в РФ), Microsoft и Uber, а также в проектах с открытым исходным кодом (например, Babel, React, Angular).

История

Идея хранения всего кода в одном месте не является новой. В ранние годы разработки программного обеспечения, когда системы контроля версий были примитивными (например, SCCS или RCS), разработчики часто хранили все файлы проекта в одной директории. С появлением распределённых систем контроля версий, в частности Git, сообщество разделилось на сторонников монорепозиториев и мультирепозиториев.

В 2000-х годах Google, Microsoft и Facebook (организация признана экстремистской и запрещена в РФ) независимо друг от друга разработали внутренние инструменты для работы с монорепозиториями гигантского масштаба. Например, репозиторий Google (Piper) содержит миллиарды файлов и обслуживается собственной файловой системой. В 2015 году компания Facebook (организация признана экстремистской и запрещена в РФ) выпустила инструмент Buck, а затем — Mercurial с расширением Mononoke для работы с монорепозиториями. В 2017 году компания Microsoft начала миграцию ядра .NET в единый монорепозиторий на GitHub.

В русскоязычной среде монорепозитории получили распространение с ростом популярности TypeScript и инструментов сборки, таких как Nx, Lerna и Turborepo. Крупные российские IT-компании, включая Яндекс и VK, также используют монорепозитории для внутренних проектов.

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

Единая история изменений

Все коммиты, ветки и теги для разных проектов хранятся в одном репозитории. Это позволяет легко отслеживать изменения, затрагивающие несколько компонентов одновременно, и выполнять атомарные коммиты (когда одно изменение вносится сразу в несколько пакетов).

Общие инструменты и конфигурации

Монорепозиторий позволяет централизованно управлять линтерами, форматтерами, системами сборки и тестирования. Единая конфигурация CI/CD (непрерывной интеграции и доставки) упрощает поддержку и снижает дублирование.

Прозрачность и доступность

Любой разработчик в организации может просмотреть код любого модуля, библиотеки или сервиса, что способствует обнаружению дублирования, повторному использованию кода и улучшению кросс-командного взаимодействия.

Масштабируемость

Монорепозитории могут содержать тысячи проектов и миллионы файлов. Для эффективной работы с ними требуются специализированные инструменты, такие как Google Bazel, Facebook (организация признана экстремистской и запрещена в РФ) Buck, Nx, Turborepo, а также расширения Git (например, git sparse-checkout, git subtree).

Преимущества

Упрощение управления зависимостями

В монорепозитории все версии библиотек и пакетов согласованы. Исключается проблема «ада зависимостей» (dependency hell), когда разные проекты требуют несовместимых версий одной библиотеки. Разработчик может вносить изменения в библиотеку и сразу же тестировать их во всех зависимых проектах.

Атомарные изменения

Одно изменение (коммит) может затрагивать несколько модулей, сервисов или библиотек. Это гарантирует, что после коммита всё приложение остаётся в согласованном состоянии. Например, изменение API в библиотеке и обновление всех её потребителей происходит в одном коммите.

Унификация инструментов

Единые настройки сборки, тестирования, линтинга и форматирования снижают когнитивную нагрузку на разработчиков. Нет необходимости настраивать окружение для каждого проекта отдельно.

Повторное использование кода

Код, общий для нескольких проектов (утилиты, типы, компоненты UI), может быть легко обнаружен и использован без публикации отдельного пакета в реестр пакетов (npm, PyPI, Maven). Это ускоряет разработку и уменьшает дублирование.

Упрощение рефакторинга

Крупные рефакторинги (например, переименование функции или изменение структуры данных) могут быть выполнены сразу во всех проектах. Инструменты статического анализа и IDE поддерживают навигацию по всему монорепозиторию.

Недостатки

Масштабирование Git

Стандартный Git плохо справляется с репозиториями, содержащими сотни тысяч файлов. Операции clone, fetch, status и log замедляются. Для решения этой проблемы используются расширения (git sparse-checkout, git partial clone) или альтернативные системы контроля версий (Mercurial, Perforce).

Сложность CI/CD

Необходимо настроить умную систему сборки, которая будет запускать только тесты и сборки для изменённых модулей, а не для всего репозитория. Иначе время выполнения CI может стать неприемлемо большим. Инструменты вроде Nx, Bazel и Turborepo решают эту задачу с помощью графа зависимостей и кэширования.

Управление доступом

В монорепозитории сложнее разграничить права доступа для разных команд. Git не предоставляет встроенных механизмов для ограничения доступа к отдельным директориям. Решения включают использование CODEOWNERS, отдельных веток или специализированных платформ (GitLab, Gerrit).

Риск «загрязнения» истории

Большое количество коммитов от разных команд может усложнить историю изменений. Требуются строгие практики работы с ветками (например, trunk-based development) и автоматизированные проверки.

Инструменты для работы с монорепозиториями

Системы контроля версий

Git — наиболее популярная система. Для больших репозиториев используются расширения: git sparse-checkout, git subtree, git worktree.
Mercurial — используется Facebook (организация признана экстремистской и запрещена в РФ) с расширением Mononoke.
Perforce — используется в некоторых крупных компаниях (например, Google до перехода на Piper).

Инструменты управления сборкой и зависимостями

Bazel (Google) — поддерживает многоплатформенную сборку, кэширование и параллельные задачи.
Nx (Nrwl) — популярен в экосистеме JavaScript/TypeScript, поддерживает Angular, React, Node.js.
Turborepo (Vercel) — быстрый инструмент для JavaScript-монорепозиториев с продвинутым кэшированием.
Lerna — один из первых инструментов для JavaScript, сейчас считается устаревшим в пользу Nx и Turborepo.
Buck (Facebook, организация признана экстремистской и запрещена в РФ) — система сборки для больших монорепозиториев.
Pants — система сборки для Python, Java, Scala и Go.

Платформы хостинга

GitHub — поддерживает монорепозитории, но имеет ограничения на размер (рекомендуется до 5 ГБ).
GitLab — предоставляет встроенные инструменты для работы с монорепозиториями и CI/CD.
Bitbucket — поддерживает монорепозитории, но менее популярен для крупных проектов.

Применение

Крупные технологические компании

Google — хранит весь код (включая Android, Chrome, Google Search) в едином монорепозитории Piper, использующем собственную файловую систему и инструмент Bazel.
Meta (организация признана экстремистской и запрещена в РФ) — использует монорепозиторий на основе Mercurial с расширением Mononoke. Код Facebook (организация признана экстремистской и запрещена в РФ), Instagram (продукт Meta, признанной экстремистской и запрещённой в РФ), WhatsApp (продукт Meta, признанной экстремистской и запрещённой в РФ) и других продуктов хранится вместе.
Microsoft — после покупки GitHub активно переводит проекты (например, .NET, TypeScript, VS Code) в монорепозитории.
Uber — использует монорепозиторий на основе Go и Bazel для микросервисной архитектуры.

Проекты с открытым исходным кодом

Babel — компилятор JavaScript, включает множество пакетов в одном репозитории.
React — библиотека для пользовательских интерфейсов, содержит ядро, DOM-рендерер, серверный рендеринг и тестовые утилиты.
Angular — фреймворк, включает компилятор, CLI, материалы и множество модулей.
Vue.js — экосистема Vue (ядро, роутер, Vuex, DevTools) хранится в монорепозитории.

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

Яндекс — использует монорепозиторий для внутренних сервисов и библиотек.
VK — применяет монорепозиторий для фронтенд-проектов.
СберТех — использует монорепозитории для Java-микросервисов.

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

Параметр	Монорепозиторий	Мультирепозиторий
Управление зависимостями	Централизованное, согласованные версии	Децентрализованное, риск несовместимости версий
Атомарные изменения	Поддерживаются	Требуют синхронизации между репозиториями
Масштабирование Git	Требует специальных инструментов	Ограничено размером каждого репозитория
Разграничение доступа	Сложное	Естественное (по репозиторию)
Повторное использование кода	Простое	Требует публикации пакетов
Рефакторинг	Упрощён	Сложен, требует координации

Критика

Основные критические замечания в адрес монорепозиториев связаны с техническими ограничениями Git и необходимостью использования сложных инструментов. Противники подхода утверждают, что монорепозитории подходят только для крупных организаций с высокой культурой разработки и большими инвестициями в инфраструктуру. Для небольших команд или стартапов мультирепозиторная стратегия часто оказывается проще и дешевле в поддержке.

Также отмечается, что монорепозиторий может привести к «раздуванию» кодовой базы, когда разработчики включают в репозиторий код, который редко используется, что затрудняет навигацию и увеличивает время сборки.

См. также

Источники

Документация Nx (Nrwl)
Bazel Build System (Google)
Monorepo Patterns and Practices (Meta, организация признана экстремистской и запрещена в РФ)
«The Monorepo Approach» (Microsoft)
Статья «Why Google Stores Billions of Lines of Code in a Single Repository» (Communications of the ACM)

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →