{"schema_version":"1.0","service":"Publicasta","type":"article","id":959,"slug":"github_agent_scale_git_infrastructure_read_write_scaling","title":"GitHub перестраивает Git-инфраструктуру под нагрузку от агентов, разделяя чтение репозиториев и координацию записи","excerpt":"GitHub перестраивает слой хранения GitHub.com по мере роста активности репозиториев, вызванной разработкой с участием агентов. Для инженерных команд главный вывод — контролировать веерную запись, горячие ссылки, чтение CI и правила работы во время миграции.","language":"ru","default_language":"en","canonical_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling?lang=ru","image":{"url":"https://publicasta.com/storage/projects/17/pages/959/2026/10/418e0579-8964-4938-8a97-720d1dd31b10.webp","alt":"Редакционная визуализация облачной инфраструктуры, разделяющей чтение репозиториев и координацию записей Git."},"publisher":{"id":17,"slug":"it_today_news","name":"ИТ сегодня","url":"https://publicasta.com/it_today_news"},"author":{"name":"Anton R"},"published_at":"2026-10-24T13:39:10+00:00","updated_at":"2026-10-24T13:39:10+00:00","content_markdown":"GitHub перестраивает архитектуру хранения своего Git-сервиса под модель разработки, в которой люди, системы CI и программные агенты могут одновременно записывать данные в одни и те же репозитории. В свежей инженерной публикации компании описана схема, переносящая долговечные данные репозиториев в Azure Blob Storage, позволяющая независимо масштабировать мощности чтения и сужающая область координации записи с уровня репозитория до отдельных Git-ссылок, для которых действительно требуется упорядочивание.\n\n ![Редакционная визуализация облачной инфраструктуры, разделяющей чтение репозиториев и координацию записей Git.](https://publicasta.com/storage/projects/17/pages/959/2026/10/418e0579-8964-4938-8a97-720d1dd31b10.webp)\n\n Это существенное изменение инфраструктуры, но не новая функция, которую пользователи могут включить. GitHub представляет работу как продолжающуюся перестройку, выполняемую при работающей платформе. Согласно последующей публикации, компания уже перенесла копии 99,99999% репозиториев в Azure, однако для оставшихся нестандартных случаев требуются изменения протокола записи. В публикациях также сообщается о росте внутренней пропускной способности, но подробностей бенчмарков недостаточно, чтобы считать эти показатели гарантией ёмкости для конкретного предприятия или парка агентов.\n\n Поэтому для платформенных команд ближайший вопрос заключается не в том, станет ли репозиторий внезапно работать в 35 раз быстрее. Важно спроектировать автоматизированные процессы разработки так, чтобы они не зависели от превращения каждой контрольной точки в push, от использования одной и той же горячей ссылки всеми ветками или от многократного клонирования одних и тех же данных каждым заданием CI.\n\n ## Что меняет GitHub\n\n Существующая архитектура GitHub, описанная в инженерной серии компании под названием Spokes, хранит полные копии репозиториев на узлах хранения и использует координацию записи на основе кворума. Такая схема обеспечивает долговечность и согласованность, но связывает между собой несколько разных задач. Один и тот же общий набор реплик участвует в обеспечении надёжности записи, обслуживает чтение Git и поддерживает операции обслуживания, такие как компактификация и сборка мусора.\n\n Эта связанность становится дороже, когда нагрузка одновременно растёт в нескольких направлениях. Агент может создавать коммиты или контрольные точки значительно чаще человека-разработчика. Большой парк агентов способен создавать множество веток в одном репозитории. После каждого изменения CI может веерообразно запускать чтение от вершины ветки. Затем очереди слияния и автоматизация выпуска могут концентрировать записи на небольшом числе ссылок.\n\n Перестройка GitHub опирается на два связанных принципа: координировать только то, что действительно необходимо координировать, и отделить долговечное хранилище от вычислительных ресурсов, обслуживающих запросы.\n\n Первый принцип относится к обновлению ссылки внутри Git push. Git-репозиторий содержит неизменяемые объекты, идентифицируемые их содержимым, а также изменяемые ссылки — указатели на ветки и теги. Именно обновление ссылки требует упорядочивания: если клиент увидел новое значение ссылки, последующие чтения не должны возвращать более старое. Многие другие операции вокруг push, включая хранение объектов, проверку соединения, сканирование секретов и обслуживание, можно выполнять параллельно или вынести за пределы узкого пути подтверждения.\n\n Второй принцип меняет способ использования копий репозиториев. Вместо того чтобы требовать от каждого работника, обслуживающего чтение, быть также полноценной долговечной репликой, GitHub описывает модель, в которой Azure Blob Storage становится долговечным источником, а лёгкие работники обеспечивают кэшированную ёмкость чтения. Сбой работника в такой схеме скорее означает потерю кэша или вычислительного ресурса, а не потерю авторитетной копии репозитория. Новых работников можно добавлять для кратковременных всплесков чтения, не увеличивая автоматически сопоставимым образом стоимость каждой записи.\n\n Архитектура внедряется постепенно. В публикациях GitHub виртуальные реплики, работники с опорой на хранилище, сериализация на уровне отдельных ссылок и фоновые операции обслуживания описываются как части миграции, а не как единый уже завершённый запуск продукта.\n\n ## Почему рабочие нагрузки агентов выявили старое узкое место\n\n Изменение часто описывают как историю об «инфраструктуре для ИИ», но причина давления точнее: разработка программного обеспечения с высокой степенью параллелизма создаёт иное распределение операций Git.\n\n Человеческий разработчик может несколько минут работать, прежде чем создать коммит и отправить ветку. Автоматизированный агент способен сохранять контрольную точку после каждой отдельной задачи, запускать тесты, редактировать файлы и повторять этот цикл. Поэтому тысячи агентов, работающих с одной кодовой базой, могут генерировать множество одновременных операций записи и чтения, попыток слияния и обновлений статуса. Для этого не требуется, чтобы агенты были автономными в широком смысле. Скриптовый цикл разработки, подключённый к модели, создаст такую же нагрузку на инфраструктуру, если будет часто обращаться к репозиторию.\n\n GitHub сообщает, что ежемесячная активность Git выросла с 218,2 млрд событий в сентябре 2025 года до 473,3 млрд в августе 2026 года. Компания также указывает 7,38 млрд коммитов в сентябре, 3,35 млрд ежемесячных отправок, почти четырёхкратный рост числа слияний pull request и 3,26 млрд запусков GitHub Actions за этот месяц. Эти показатели отражают общую активность платформы, а не точное измерение активности, вызванной одними агентами. В них входят обычная работа разработчиков, CI, автоматизация и рост числа клиентов. Тем не менее они показывают, почему сервис репозиториев, рассчитанный на меньший уровень параллелизма, оказался на повестке пересмотра.\n\n Давление возникает не только из-за операций записи. Репозиторий с большим числом агентов или процессов CI может получать всплеск запросов на fetch, клонирование, проверку статуса и операций с pull request после каждого обновления ветки. Если ёмкость для чтения привязана к тем же полным репликам, которые участвуют в кворуме записи, масштабирование чтения может сделать запись дороже. Если для поглощения всплеска чтения репозиторию требуется множество дополнительных реплик, они могут увеличить объём координации и сопровождения, даже если схема записи не изменилась.\n\n Перестройка призвана разорвать эту обратную связь. Рабочие узлы чтения можно масштабировать в соответствии со спросом, тогда как долговечное состояние репозитория и упорядоченные обновления ссылок остаются в отдельном слое. Это не делает каждую операцию Git дешёвой и не отменяет необходимость согласованности. Меняется место, где система расходует свой бюджет на координацию.\n\n ## Координация на уровне отдельных ссылок — ключевая деталь дизайна\n\n Самая полезная техническая деталь в последнем объяснении GitHub — переход от координации на уровне всего репозитория к сериализации на уровне отдельных ссылок.\n\n При блокировке всего репозитория или эквивалентном сериализованном пути записи две отправки могут мешать друг другу, даже если обновляют независимые ветки. Отправка в `feature/alice` ждёт завершения отправки в `feature/bob`, потому что репозиторий является единицей, на уровне которой система координирует обновление. Такой подход прост для понимания, но его пропускная способность ограничена самой медленной репликой, сетевыми обменами, необходимыми для кворума, и количеством записей, которые могут пройти через общую очередь.\n\n Сериализация на уровне ссылок сужает область конфликта. Обновления одной и той же ветки по-прежнему нужно упорядочивать. Две принудительные отправки в одну ссылку нельзя считать независимыми, поскольку их итоговое состояние зависит от порядка и политики. Но обновления разных веток могут выполняться параллельно, если они не нарушают правила согласованности Git или политики управления репозиторием.\n\n GitHub утверждает, что внутреннее тестирование нового подхода показало: в сценарии миграции, описанном компанией, записи в разные ссылки обеспечивали примерно в 3–4 раза более высокую пропускную способность при меньшей задержке. Этот результат конкретнее широко цитируемой в предыдущей публикации об архитектуре цифры «до 35 раз выше пропускная способность записи», однако оба показателя остаются результатами внутренних измерений. В опубликованных материалах недостаточно сведений о размере репозитория, параллелизме, составе нагрузки, базовом оборудовании, перцентилях задержки и развёртывании в production, чтобы внешняя команда могла напрямую перевести эти цифры в формулу расчёта ресурсов.\n\n Это различие важно для инженерного планирования. Репозиторий с тысячами независимых недолговечных веток может выиграть от снижения конкуренции. Но в нагрузке, где тысячи рабочих процессов обновляют одну общую ветку, один release tag или одну очередь слияния, всё равно остаётся горячая ссылка. Координация на уровне ссылок ограничивает конкуренцию между несвязанными операциями, но не превращает один упорядоченный поток в бесконечно параллельный.\n\n ## Надёжное хранение и масштабирование чтения\n\n Модель объектов Git с адресацией по содержимому позволяет отделить неизменяемые данные от изменяемого состояния ссылок. После сохранения и проверки объекта его идентификатор определяется содержимым. Изменяемая часть репозитория сравнительно мала: ссылки перемещаются, а система должна обеспечивать клиентам порядок, согласованный с этими перемещениями.\n\n GitHub называет Azure Blob Storage долговечным уровнем хранения данных репозиториев и вводит виртуальную реплику записи, которая передаёт поступающие записи в объектное хранилище. Запись подтверждается только после того, как данные становятся долговечными на этом уровне. Затем облегчённые реплики чтения могут прогревать кэши из объектного хранилища и обслуживать трафик чтения, не подключаясь к кворуму записи так же, как полноценная долговечная реплика.\n\n Преимущество не сводится к тому, что «облачное хранилище работает быстрее». Объектное хранилище и вычислительные ресурсы для обслуживания запросов можно предоставлять и восстанавливать независимо друг от друга. Рабочий процесс чтения можно добавить, когда спрос создают выпуск, веерный запуск CI или парк агентов. Отказавший рабочий процесс чтения можно заменить и заново заполнить его кэш. Обслуживание хранилища могут выполнять отдельные рабочие процессы, не конкурируя напрямую с активными fetch- и push-операциями на тех же машинах.\n\n У такого подхода есть компромиссы. Новый рабочий процесс чтения может начать работу с пустым кэшем. Согласование с долговечным хранилищем должно корректно выполняться при параллельных обновлениях. Для одних запросов может требоваться более свежее состояние ссылок, чем для других, поэтому одной фоновой синхронизации может быть недостаточно. GitHub сообщает, что на следующих этапах больше операций согласования будет перенесено в путь обработки запроса: реплика сможет получить состояние ссылок и данные, изменившиеся с момента её последнего обновления.\n\n Иными словами, архитектура не устраняет проблему, а переносит её. Теперь вместо участия каждой полноценной реплики в каждой операции системе нужно управлять актуальностью кэша, долговечным состоянием ссылок, восстановлением, компакцией и границами между обслуживанием запросов и техническим сопровождением. Такая конструкция привлекательна тем, что эти обязанности можно масштабировать независимо, однако независимость требует явно заданных правил согласованности и хорошей наблюдаемости.\n\n ## К цифре «35 раз» нужно отнестись внимательно\n\n В более ранней публикации GitHub говорится, что перестроенная архитектура обеспечила во внутренних тестах до 35-кратного роста пропускной способности записи. Это полезный сигнал о направлении работы, но не обещание, что конкретный репозиторий клиента получит улучшение в 35 раз.\n\n В открытой публикации недостаточно сведений о конфигурации теста, чтобы определить, к каким условиям относится эта цифра. Не указаны размер репозитория, число ссылок, уровень параллелизма, распределение записей, соотношение чтения и записи, базовая система, распределение задержек, условия отказов и то, моделирует ли тест производственный трафик. Также не сказано, что все репозитории уже переведены на новый путь или что измерение отражает общедоступное ограничение сервиса.\n\n Такая же осторожность нужна при оценке статистики активности компании. Быстрый рост числа push-операций и коммитов показывает нагрузку на платформу, но не доказывает, что весь рост вызван агентами. Он также не означает, что большее число операций Git пропорционально увеличивает объём полезного программного обеспечения. Большое количество автоматических контрольных точек может быть результатом продуктивной параллельной работы, ненужной активности, повторных попыток или сочетания всех трёх факторов.\n\n Практический вывод прост: не рассчитывайте размер агентной платформы, умножая текущий параллелизм на громкий показатель из теста. Воспринимайте этот тест как свидетельство того, что GitHub устраняет структурное узкое место, а собственную нагрузку измеряйте по задержке push-операций, отклонённым или повторным push-операциям, ограничениям API, времени ожидания в очереди, веерному запуску CI и времени до слияния.\n\n ## Что это означает для инженерных команд уже сейчас\n\n Из-за этого объявления пользователям не нужно переписывать обычные рабочие процессы Git. Заявленная цель GitHub — сохранить ветвление, ревью, слияние, историю, защиту веток, обязательные ревью, журналы аудита, видимость репозиториев и другие механизмы контроля, изменив при этом внутренний серверный слой, который их обслуживает.\n\n Командам, запускающим автоматизацию в больших объёмах, всё же стоит пересмотреть устройство своих нагрузок. Такая проверка полезна даже в том случае, если миграция GitHub со временем снимет значительную часть текущего давления: она сокращает напрасную работу и упрощает восстановление после сбоев.\n\n ### Сократите ненужную частоту push-операций\n\n Агенту необязательно отправлять каждую промежуточную контрольную точку в общую удалённую ветку. По возможности сохраняйте промежуточные состояния локально, а затем отправляйте значимые этапы или ограниченную по размеру партию изменений. Подходящая частота зависит от требований к восстановлению и цены потери локальной работы, но политика, превращающая каждый вызов инструмента в удалённый push, создаёт избыточный трафик записи.\n\n Для длительных задач сохраняйте локальные или внешние контрольные точки отдельно от обновления ветки, если команде требуется детальное восстановление. Так требование к надежному восстановлению остается отделенным от Git-ссылки, которую должны использовать другие разработчики и системы.\n\n ### Не создавайте единственную горячую ссылку\n\n Тысячи независимых веток все равно могут сходиться в одной защищенной ветке, теге релиза или очереди слияния. Определите ссылки с наибольшей частотой записи и рабочие процессы, которые на них сериализуются. Репозиторий может демонстрировать отличную совокупную параллельность веток, но одна общая ссылка при этом останется фактическим узким местом.\n\n Используйте очереди слияния и контролируемую пакетную обработку там, где они улучшают порядок операций, но следите за возрастом очереди и поведением повторных попыток. Очередь, которая снова и снова пересчитывает или проверяет один и тот же большой набор изменений, может перенести нагрузку с операций записи Git на CI, API запросов на слияние или тестовую инфраструктуру.\n\n ### Делайте чтение из CI осознанным\n\n Автоматизация с большим объемом чтения способна перегрузить репозиторий даже при умеренном количестве отправок. По возможности используйте поверхностные или частичные клонирования, повторно применяйте кэши репозитория, не выполняйте полное клонирование одних и тех же входных данных и распределяйте веерный запуск, когда релиз или обновление ветки одновременно инициирует множество заданий.\n\n В рекомендациях GitHub для репозиториев советуют соблюдать такие эксплуатационные ограничения, как размер отправки до 2 ГБ, рекомендуемый предел в 15 операций чтения Git в секунду на репозиторий и рекомендуемая частота отправок — шесть в минуту на репозиторий. Это не заменяет планирование емкости и не описывает каждую конфигурацию API или корпоративной среды, но напоминает, что репозиторий — общая граница сервиса. Автоматизированные клиенты должны учитывать опубликованные ограничения при проектировании, а не узнавать о них через троттлинг.\n\n ### Не позволяйте повторным попыткам усиливать инцидент\n\n Сбой отправки или получения данных может заставить большой парк автоматизации повторить операцию в один и тот же момент. Используйте экспоненциальную задержку со случайным разбросом, ограничивайте число попыток, отделяйте временные транспортные ошибки от отказов политики и сохраняйте исходный идентификатор операции или диапазон коммитов, чтобы повторная попытка не создавала дублирующую работу.\n\n Политика повторных попыток должна учитывать и человеческую проверку. Если рабочий процесс ожидает обновления защищенной ветки, бездумные повторы могут перегружать ту же ссылку, пока оператор разбирается в ситуации. Задержка — это средство обеспечения надежности, а не просто настройка производительности на стороне клиента.\n\n ### Сохраняйте управление при росте автоматизации\n\n GitHub заявляет, что новая инфраструктура призвана сохранить защиту веток, обязательные проверки, журналы аудита и видимость репозиториев. Организациям следует убедиться, что их агентские рабочие процессы явно опираются на эти механизмы. Более быстрый путь записи не заменяет правила утверждения, сканирование секретов, подписанные коммиты там, где они обязательны, защиту окружений и проверки развертывания.\n\n Агенты должны получать только минимальные разрешения для репозитория и окружения, необходимые им для выполнения задачи. Разделяйте доступ к генерации кода, полномочия на слияние, учетные данные для развертывания и доступ к производственным данным. Если агент может создавать ветки, но не способен обновить защищенную ветку по умолчанию без проверки, улучшения масштабирования платформы повышают пропускную способность, не устраняя незаметно человеческую точку принятия решения.\n\n ## Что пока неизвестно\n\n В публичном описании GitHub по-прежнему остаются открытыми несколько важных вопросов.\n\n Компания не опубликовала полный график развертывания новой архитектуры. Не сообщается, сколько производственных репозиториев обслуживается моделью чтения на основе хранилища, какие рабочие нагрузки подходят для нее и когда клиенты смогут заметить изменения ограничений и задержек.\n\n Заявления о результатах тестов также требуют дополнительного контекста. Внешним читателям нужны определения рабочих нагрузок, размеры репозиториев, уровни параллелизма, задержки p50 и p99, поведение при сбоях и сравнения с существующим путем. Без этих данных формулировка «до» остается полезным инженерным сигналом, но не гарантией, на которую можно опираться при планировании.\n\n Еще одна область для наблюдения — согласованность при прогреве кэша. Рабочий узел, восстанавливающий состояние из объектного хранилища, не должен возвращать устаревшие значения ссылок, нарушающие ожидания Git. Система также должна обрабатывать уплотнение, сборку мусора, прерванные записи, задержки между регионами и восстановление после частичных сбоев, не превращая обслуживание в новое узкое место при обслуживании запросов.\n\n Наконец, связь между активностью агентов и заявленным ростом платформы пока измерена лишь частично. Статистика GitHub объединяет работу людей-разработчиков, обычной автоматизации, CI и агентских сценариев. Этого достаточно, чтобы обосновать архитектурные изменения, но недостаточно, чтобы утверждать: каждая организация столкнётся с такой же картиной конкуренции.\n\n ## Практический смысл объявления\n\n GitHub реагирует на реальное изменение характера разработки: операций с репозиториями становится больше, ветки выполняются параллельнее, автоматизированных чтений — больше, а общие точки интеграции испытывают всё большую нагрузку. Ответ компании — сократить необязательную координацию, отделить долговременное хранение от вычислительных ресурсов, обслуживающих запросы, и по возможности сделать ёмкость для чтения независимой от кворума записи.\n\n Для клиентов ближайший вывод — дисциплина работы с нагрузкой. Не превращайте промежуточное состояние агентов в постоянный удалённый Git-трафик, выявляйте горячие ссылки, контролируйте разрастание CI, кэшируйте повторные чтения и выполняйте повторы с умеренной частотой. Даже по мере роста возможностей автоматизации продолжайте соблюдать границы ревью и развёртывания.\n\n Архитектура со временем может дать GitHub значительно больший запас по нагрузке, однако опубликованные бенчмарки не отменяют необходимости измерять реальные рабочие сценарии. Для платформенной команды полезный вопрос заключается не в том, объявил ли GitHub о большом многократном росте производительности. Важно понять, какая часть цикла разработки команды сейчас выполняется последовательно, действительно ли такая последовательность необходима и что произойдёт, когда придёт следующая волна автоматизированной работы.","available_translations":[{"language":"ar","title":"إعادة بناء Git لدى GitHub على نطاق الوكلاء تفصل بين قراءة المستودعات وتنسيق الكتابة","html_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling?lang=ar","markdown_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.md?lang=ar","json_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/github_agent_scale_git_infrastructure_read_write_scaling?lang=ar"},{"language":"de","title":"GitHubs Git-Neuaufbau für agentenbasierte Skalierung trennt Repository-Lesezugriffe von der Schreibkoordination","html_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling?lang=de","markdown_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.md?lang=de","json_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/github_agent_scale_git_infrastructure_read_write_scaling?lang=de"},{"language":"en","title":"GitHub’s Agent-Scale Git Rebuild Separates Repository Reads from Write Coordination","html_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling?lang=en","markdown_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.md?lang=en","json_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/github_agent_scale_git_infrastructure_read_write_scaling?lang=en"},{"language":"es","title":"La reconstrucción de Git de GitHub a escala de agentes separa las lecturas del repositorio de la coordinación de escrituras","html_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling?lang=es","markdown_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.md?lang=es","json_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/github_agent_scale_git_infrastructure_read_write_scaling?lang=es"},{"language":"fr","title":"La refonte de Git à l’échelle des agents par GitHub sépare les lectures des dépôts de la coordination des écritures","html_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling?lang=fr","markdown_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.md?lang=fr","json_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/github_agent_scale_git_infrastructure_read_write_scaling?lang=fr"},{"language":"pl","title":"GitHub przebudowuje Git na skalę agentów, oddzielając odczyty repozytoriów od koordynacji zapisów","html_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling?lang=pl","markdown_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.md?lang=pl","json_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/github_agent_scale_git_infrastructure_read_write_scaling?lang=pl"},{"language":"ru","title":"GitHub перестраивает Git-инфраструктуру под нагрузку от агентов, разделяя чтение репозиториев и координацию записи","html_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling?lang=ru","markdown_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.md?lang=ru","json_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/github_agent_scale_git_infrastructure_read_write_scaling?lang=ru"},{"language":"zh","title":"GitHub 面向代理规模重建 Git 基础设施，将仓库读取与写入协调分离","html_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling?lang=zh","markdown_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.md?lang=zh","json_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/github_agent_scale_git_infrastructure_read_write_scaling?lang=zh"}],"_links":{"self":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.json?lang=ru","api":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/github_agent_scale_git_infrastructure_read_write_scaling?lang=ru","html":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling?lang=ru","canonical":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling?lang=ru","markdown":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.md?lang=ru","json":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.json?lang=ru","channel":"https://publicasta.com/api/public/v1/channels/it_today_news","channel_articles":"https://publicasta.com/api/public/v1/channels/it_today_news/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}