Ing. Calogero Bono
GitHub рассказал о Rubicon, новой архитектуре хранения Git, анонсированной на GitHub Universe. По словам компании, во внутренних тестах она выдержала 5 000 одновременных агентов в одном репозитории, 7 200 пушей в секунду и низкую задержку чтения. Это важно, потому что агенты для программирования меняют нагрузку на репозитории, и то, что GitHub тянет сегодня, через год может уже не хватать.
Несколько терминов, прежде чем перейти к фактам. Агент — программа на основе ИИ, которая сама пишет код и делает пуши. Reference — указатель на коммит, как ветка. Pack — файл, в котором собраны объекты Git. Compare-and-swap — операция, которая обновляет значение только если никто его не изменил за это время. Blob Storage — сервис объектного хранения Azure.
Что такое Rubicon и зачем его построила GitHub?
Rubicon — название проекта, в рамках которого GitHub переработала то, как хранит и отдаёт данные Git. Согласно статье GitHub, работа началась в мае 2026 года, сразу после первоначальной миграции в Azure.
Причина в нагрузке. GitHub заявляет, что сегодня самые загруженные репозитории получают максимум десятки записей в секунду короткими всплесками. Учитывая, что агенты работают параллельно и непрерывно, компания ожидает, что через год это станет постоянным ритмом. Поэтому она поставила цель как минимум на два порядка больше.
Какие требования к масштабу поставила GitHub?
GitHub выделяет две оси. Горизонтальное масштабирование касается множества репозиториев, и здесь работают уже проверенные решения – партиционирование и маршрутизация по нагрузке. Вертикальное масштабирование касается одного очень большого и активного репозитория, и именно отсюда идут почти все требования.
Для одного репозитория архитектура должна принимать тысячи записей в секунду и поддерживать несколько узлов записи. Также нужно снизить задержку коммитов, ведь агент ждёт каждый push перед следующим шагом. Каждый push порождает ещё больше чтений – CI, деплой и другие агенты, и GitHub говорит о сильном эффекте усиления.
Один из приведённых примеров – дневной трафик репозитория вырос примерно в 4 раза между мартом и маем.
Как устроена новая архитектура?
Исходная идея такова – согласование нужно только для обновления reference. Объекты Git неизменяемы и идентифицируются по содержимому, поэтому несколько писателей могут сохранять их одновременно. Так хранение, обслуживание запросов и обслуживание репозитория масштабируются независимо.
Запросы приходят в Spokes, который по-прежнему отвечает за маршрутизацию и балансировку. Под ним новая плоскость данных с виртуальными репликами и вычислительными узлами одноразового использования, чей локальный диск — лишь восстанавливаемый кэш. Долговечное состояние хранится в двух местах.
- Pack-файлы и данные ускорения в Azure Blob Storage.
- Reference и список pack-файлов (манифест) в Ref-CAS, реплицируемом журнальном сервисе.
Запись индексирует pack, загружает его в Blob Storage и выполняет одну транзакцию в Ref-CAS. Чтение проверяет версию reference, скачивает недостающие pack-файлы и отвечает из кэша. Упаковка pack-файлов выполняется на отдельных узлах, никогда не на репликах.
Изменится ли что-то для тех, кто ежедневно работает с Git?
По словам GitHub, нет. Git остаётся Git – push, fetch и ветки работают так же и с теми же защитами. Изменения происходят под капотом и внедряются, пока платформа продолжает работать.
Тема связана с тем, что происходит в инструментах Git для агентов, например в случае покупки Pierre компанией OpenAI. Тем, кто хорошо знает базовые команды, например Git bisect и blame, не нужно менять привычки.
Ограничения, которые стоит знать
Цифры про 5 000 агентов и 7 200 пушей в секунду взяты из внутренних тестов, которые заявляет сама GitHub, без внешней проверки. Присланный текст обрывается до подробностей о двух компонентах, поэтому технические компромиссы нам неизвестны. Полных дат внедрения для всех репозиториев не указано.
Что меняется для тех, кто работает с цифровыми сервисами
Для агентства или небольшой команды пока почти ничего. Важно другое. Если твои процессы используют агентов, которые делают много пушей, GitHub готовит платформу, чтобы она это выдерживала. Стоит всё равно продумать свой конвейер, потому что каждый пуш порождает цепочку чтений, как описано и в сравнении GitLab CI/CD и GitHub Actions. Тем, кто строит платформы с большим числом клиентов, может пригодиться принцип разделения вычислений и данных, близкий к multi-tenant.
Наше мнение
Rubicon — серьёзный инженерный проект, и идея координировать только reference элегантна. Но название говорит и о другом. GitHub считает нагрузку от агентов точкой невозврата и воспринимает её как данность. Остаётся вопрос, сбудется ли прогноз роста или синтетические тесты завысят реальное использование. Нужны независимые данные, а не только цифры самого поставщика.
Частые вопросы
Что такое Project Rubicon от GitHub?
Это новая архитектура хранения Git от GitHub, анонсированная на GitHub Universe. Она разделяет хранение и вычисления и координирует только обновления reference.
Сколько пушей в секунду она выдерживает?
Во внутренних тестах GitHub заявляет 7 200 пушей в секунду в одном репозитории при 5 000 одновременных агентах. Это данные компании, которые не проверены третьими сторонами.
Нужно ли менять то, как я использую Git?
Нет. По словам GitHub, push, fetch и ветки работают как прежде, с теми же защитами.
Где хранятся данные?
Pack-файлы лежат в Azure Blob Storage. Reference и список pack-файлов хранятся в Ref-CAS, реплицируемом журнальном сервисе.
Зачем нужно несколько реплик на один репозиторий?
Индексация pack-файлов и проверка связности объектов потребляют много CPU. Несколько узлов распределяют работу и повышают отказоустойчивость.
Что отслеживать, когда Rubicon придёт в репозитории всех
Настоящей проверкой станет переход от внутренних цифр к реальным репозиториям. Вот на что стоит обратить внимание.
- Следи за следующими статьями серии GitHub о двух подробно описанных компонентах, чтобы понять компромиссы.
- Проверь, меняется ли время push и fetch в твоих репозиториях в ближайшие месяцы.
- Смотри, публикует ли GitHub ограничения или правила использования для агентов с большим числом параллельных пушей.
