GitHub перевел stacked pull requests, то есть стеки PR, в публичное тестирование. Теперь большой diff можно разложить на цепочку связанных запросов на слияние: каждый показывает только свой слой изменений, а ревьюер не тонет в тысячах строк кода за один заход.
Для команд это не косметика в интерфейсе. Чем активнее разработчики используют Copilot, Codex и другие агенты, тем заметнее становится старая проблема: код писать стало быстрее, а проверять его людьми — нет.
Почему GitHub взялся за стеки PR именно сейчас
GitHub сам формулирует проблему без лишнего пафоса: создать pull request сегодня легче, а на его проверку человек тратит примерно столько же времени, сколько и раньше. И это уже не теория про далекое будущее, а обычная жизнь репозиториев с высоким темпом изменений.
Масштаб тоже показателен. По данным GitHub, в январе 2023 года на платформе ежемесячно сливали около 25 млн PR, сейчас — больше 90 млн. Это рост примерно в 3,6 раза. Параллельно GitHub в своем блоге ссылается на прогноз Gartner: к 2028 году асинхронные AI-агенты могут поднять продуктивность инженерных команд на 30–50%. Узкое место при таком раскладе очевидно: не генерация кода, а его проверка, согласование и доставка в прод.
Как работают стеки PR в GitHub
Стек — это цепочка из двух и более PR в одном репозитории. Нижний PR целится в main или другую базовую ветку, следующий — в ветку ниже, и так далее. В результате GitHub показывает для каждого уровня только его собственный diff, а не весь накопленный объем изменений.
В интерфейсе появилась карта стека: она показывает все уровни цепочки и их статус. Функция доступна не только в веб-версии, но и в GitHub CLI, мобильном приложении и через API. Отдельно полезно то, что правила защиты веток и CI GitHub применяет ко всем слоям стека, а не только к самому нижнему PR.
Слияние тоже сделали без ручной возни. Если смержить верхний PR, GitHub подтянет за ним все непринятые PR ниже. Если смержить середину цепочки, нижние слои уйдут вместе с ним, а верхние останутся открытыми и автоматически переназначат базовую ветку. Ограничения тоже есть: стек работает только внутри одного репозитория, а в GitHub Desktop поддержки пока нет.
Идея не новая, но теперь она встроена в GitHub
Сами стеки PR рынок придумал давно. В Meta и Google похожие сценарии годами жили в инструментах вроде Phabricator и Gerrit, а в экосистеме GitHub эту нишу закрывали сервисы наподобие Graphite. Разница в том, что теперь карта стека, правила слияния и автоматическое перебазирование веток встроены прямо в родной интерфейс GitHub, без дополнительной надстройки поверх платформы.
Для российских команд это практичная новость, а не очередная кнопка в меню. Если у вас монорепозиторий, длинные ветки и релизы тормозят из-за тяжелых проверок, стек PR помогает разложить одну большую функцию на проверяемые куски: схема данных отдельно, API отдельно, интерфейс отдельно. Особенно полезно там, где код уже генерируют агенты, а подписывать изменения и отвечать за них все еще приходится людям.
Значение для рынка разработки
GitHub фактически признает простую вещь: эпоха AI не отменяет проверку кода, а делает ее главным дефицитом. Для стартапов это способ быстрее доводить функции до релиза без гигантских PR. Для крупных компаний — шанс не ломать процессы согласования, потому что CODEOWNERS, проверки и очереди на слияние сохраняются на каждом уровне стека.
Следующий логичный шаг — довести функцию из публичного тестирования до общего доступа и посмотреть, сможет ли GitHub отвоевать у Graphite кусок рынка, который сам слишком долго оставлял другим.
Источник: GitHub Docs, GitHub Blog, GitHub Blog, InfoQ.