GitHub объявил о переработке архитектуры Git-инфраструктуры, чтобы поддержать рост автоматизированной и агентной разработки, которая приводит к резкому увеличению числа операций записи в репозитории.
По данным компании, нагрузка на GitHub стремительно растёт. Общий объём Git-событий увеличился с 218,2 млрд в месяц в сентябре 2025 года до 473,3 млрд в августе 2026 года. В сентябре разработчики и программные агенты выполнили 7,38 млрд коммитов — более чем в пять раз больше, чем годом ранее. Самый загруженный репозиторий за август обработал порядка миллиарда запросов.
GitHub связывает это с появлением практики agentic software development: в одном репозитории одновременно работают крупные инженерные команды, интенсивные CI-пайплайны и растущие парки агентов, которые генерируют и коммитят код. Для таких сценариев требуется Git-архитектура, способная выдерживать постоянные параллельные чтения и записи на уровне, который сегодня достигают лишь немногие репозитории.
Сейчас каждый репозиторий хранится в системе Spokes. Она поддерживает по несколько полных копий репозитория на локальных дисках файловых серверов (обычно пять). Это даёт низкую задержку операций чтения и резервирование за счёт дублирования. При обновлении ссылок (references) используется трёхфазный протокол коммита с кворумом, чтобы веб-интерфейс, CI и API-клиенты видели согласованное состояние репозитория.
Однако в текущей схеме один и тот же механизм отвечает за устойчивость данных и масштабирование. Локальные копии на дисках считаются основным источником истины, поэтому добавление мощности для чтения означает добавление ещё одной «надёжной» реплики. Каждая запись должна пройти через все реплики, и скорость push-операции определяется самой медленной из них. Увеличение числа реплик повышает нагрузку на записи, потеря реплики уменьшает возможности для чтения, а потеря кворума полностью блокирует записи.
Для большинства репозиториев такой компромисс приемлем. Но на экстремальных уровнях активности он превращается в ограничение, которое особенно заметно при агентной разработке. GitHub ставит задачу разделить механизмы устойчивого хранения и масштабирования без отказа от текущих преимуществ для пользователей.
Перестройка инфраструктуры идёт «на ходу»: платформа остаётся доступной, и разработчики не должны менять свои процессы ради перехода на новую архитектуру. GitHub ориентируется на самые требовательные сценарии — от корпоративной разработки под строгими регуляторными требованиями до проектов уровня операционных систем и организаций, запускающих тысячи агентов против одного кода. При этом улучшения должны поднять базовый уровень качества сервиса и для мейнтейнеров опенсорс-проектов, и для новичков с их первыми pull request.
Новая архитектура должна сохранить существующие механизмы управления: защиты веток и обязательные ревью для мейнтейнеров, аудит-логи и контроль видимости репозиториев для специалистов по безопасности, устойчивую автоматизацию и наблюдаемость для инженеров на дежурстве. GitHub подчёркивает, что развитие платформы не должно происходить за счёт управляемости и прозрачности процессов.
Компания строит новую архитектуру GitHub, опираясь на принципы распределённых систем и учитывая параллельную работу людей и агентов. Ключевая идея — развести слой долговременного хранения и слой, который обрабатывает Git-запросы, чтобы можно было независимо масштабировать чтения и записи.
GitHub отмечает, что в текущей схеме система слишком тесно связана в тех частях, где это не требуется для соблюдения семантики Git. В результате масштабирование упирается в необходимость координации между компонентами. В новом дизайне предполагается сохранить координацию там, где она критична для корректности данных, и ослабить её в остальных местах, чтобы увеличить пропускную способность на запись и количество параллельных операций.
По внутренним бенчмаркам, новая архитектура даёт до 35-кратного роста пропускной способности записей при независимом масштабировании чтений, а также устойчивое восстановление после сбоев. Система должна обеспечивать высокий уровень доступности и предсказуемости работы даже под нагрузкой от автоматизированной разработки.
GitHub заявляет, что по мере роста частоты и параллельности изменений в программных проектах платформа будет обновлять фундаментальные компоненты, сохраняя при этом привычные механизмы управления и контроля для команд. Компания уже внедряет эти принципы в инфраструктуру и обещает в следующем материале подробнее рассказать о целевой архитектуре и пути к ней.
Источник: инженерный блог GitHub, автор — Brian, Principal Software Engineer по системам хранения и базовым сервисам для репозиториев.
