Материал подготовлен по официальной инженерной статье GitHub от 6 октября 2026 года. Ниже — русская адаптация с пояснением архитектуры и цифр.

GitHub перестраивает базовую Git-инфраструктуру, потому что привычная нагрузка меняется. Репозитории теперь обслуживают не только людей, CI и ботов, но и всё больше AI-агентов, которые работают параллельно, часто делают checkpoints и создают огромное количество записей.

По данным GitHub, с сентября 2025 по август 2026 суммарная Git-активность выросла с 218,2 до 473,3 млрд событий в месяц. Только в сентябре разработчики и агенты сделали 7,38 млрд коммитов — более чем в пять раз больше, чем годом ранее.

Почему старой модели начинает не хватать

Главная проблема не в чтении репозитория, а в записи. Read-нагрузку можно масштабировать кешами и дополнительными репликами. С push сложнее: изменение должно быть надёжно записано, стать видимым для следующих операций и не нарушить согласованность refs.

GitHub отмечает несколько новых типов нагрузки:

• агенты делают коммиты и checkpoints гораздо чаще человека;
• push-операции выросли с 0,69 до 3,35 млрд в месяц — примерно в 4,9 раза;
• merge-операции pull request выросли почти в четыре раза;
• один push может породить тысячи clone и fetch со стороны CI и code scanning;
• GitHub Actions в сентябре запускался 3,26 млрд раз — более чем в четыре раза чаще, чем год назад.

Самый нагруженный репозиторий GitHub в августе получил примерно миллиард запросов.

Как GitHub хранит репозитории сейчас

Текущая архитектура использует систему Spokes. Репозиторий хранится полными копиями на локальных дисках нескольких файловых серверов, обычно пяти.

Это даёт низкую задержку чтения, резервирование и распределение запросов. При push обновление reference проходит через трёхфазный commit protocol с quorum, чтобы веб-интерфейс, API и CI видели согласованное состояние.

Но у этой схемы есть ограничение: те же копии одновременно отвечают и за durability, и за масштабирование чтения. Добавили ещё одну реплику для read capacity — она начинает участвовать и в каждой записи. В итоге push зависит от самой медленной реплики.

Новая идея — отделить durability от масштаба

GitHub хочет разъединить storage и compute.

Авторитетная копия данных репозитория будет жить в durable storage, а слой compute будет масштабироваться отдельно и кешировать данные для обслуживания Git-запросов.

Что останется на критическом пути push

GitHub отдельно подчёркивает принцип минимальной координации. При push действительно согласовать нужно обновление reference. А хранение объектов, проверку object connectivity и secret scanning можно выполнять параллельно там, где это не нарушает семантику Git.

Чем меньше работы остаётся на критическом пути, тем быстрее агент может закончить push и перейти к следующему действию.

Обслуживание репозитория уйдёт с serving path

Compaction и garbage collection — тяжёлые операции. Сейчас они могут выполняться на тех же хостах, которые обслуживают живые Git-запросы.

В новой архитектуре GitHub планирует вынести такую работу в отдельные workers, работающие напрямую с durable storage. Это позволяет оптимизировать большой репозиторий в фоне, не замедляя push и fetch.

Azure Blob Storage как авторитетный слой

В описанной архитектуре авторитетные данные репозитория будут находиться в Azure Blob Storage. Compute-слой поверх него можно масштабировать отдельно.

Потеря compute worker тогда больше похожа на потерю кеша, а не на потерю части durable-копии репозитория. Новый worker может быстро начать обслуживать запросы и постепенно заполнить кеш данными из storage.

Что это даёт AI-агентам

Человек не замечает лишние десятки или сотни миллисекунд в отдельном push. У агента, который делает множество коротких итераций подряд, эта задержка начинает напрямую ограничивать скорость всей задачи.

Ещё сложнее сценарий, когда тысячи агентов работают в одном репозитории на собственных ветках. Тогда постоянные записи, CI, code scanning и merges сходятся в одну инфраструктурную точку.

Поэтому GitHub строит архитектуру не под один «сильный» AI-агент, а под большое количество конкурентных процессов.

Люди должны сохранить контроль

При всей ориентации на agent-scale GitHub отдельно выделяет governance. Branch protection, required reviews, audit logs и правила merge не должны исчезнуть ради скорости.

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

До 35 раз выше write throughput

GitHub сообщает, что во внутренних benchmark новая архитектура показывала до 35 раз более высокий write throughput. При этом read capacity масштабируется отдельно под фактический спрос.

Это внутренние показатели GitHub, а не универсальный benchmark для любого Git-сервера, но они показывают масштаб ожидаемого изменения.

Почему это важно даже без тысяч агентов

Архитектура строится под самые тяжёлые workloads, но GitHub рассчитывает, что выгоду получат обычные проекты тоже: быстрее восстановление после отказов, независимое масштабирование чтения, меньше конкуренции между maintenance и живыми запросами.

Сам тренд важнее конкретной реализации. AI-разработка начинает менять уже не только IDE и code review, но и фундаментальную инфраструктуру хранения кода.

Недавно GitHub также выпустил Git 2.56, а Copilot Code Review теперь можно запускать через API. Для собственных CI/CD-процессов можно посмотреть материал про автоматизацию GitHub Actions.

Официальный источник

GitHub Blog — Building Git infrastructure for agent-scale development