GitHub выпустил стек пул-реквестов (Stacked PRs) в публичном превью
GitHub объявил о публичном превью стека пул-реквестов (stacked pull requests), функции, которая разбивает большие изменения на упорядоченную серию небольших, легко проверяемых пул-реквестов. Каждый такой PR представляет отдельный слой изменения; их можно ревьюить и проверять по отдельности, а затем слить всё разом одним кликом. Идея в том, чтобы избавиться от гигантских PR, которые review-команда мучительно долго разбирает, и от ручной перебазировки веток, разбросанных по нескольким ответвлениям.
Стеки работают внутри самого GitHub, поэтому существующие ревью, проверки (checks) и требования к мержу применяются к ним без дополнительной настройки. Открыть отдельный PR в стеке можно, чтобы увидеть только диф этого конкретного слоя, а специальная карта стека наверху страницы показывает, как этот слой соотносится с остальной работой, это позволяет нескольким разработчикам параллельно ревьюить разные слои, не блокируя друг друга.
Слияние устроено гибко: если смержить самый готовый (верхний по готовности) PR стека, вместе с ним уйдут и все нижележащие слои. Можно смержить и только часть стека, тогда оставшиеся выше пул-реквесты останутся открытыми и автоматически перебазируются и перенацелятся на новую базу. Существующие защиты веток и обязательные проверки продолжают действовать на всё, что попадает в main.
Начать работу со стеком можно из расширения GitHub CLI (gh extension install github/gh-stack), создать первую ветку и PR, а затем добавлять поверх новые ветки и пул-реквесты, каждый из которых нацелен на слой под собой. Работать со стеками можно на github.com, через GitHub CLI, в мобильном приложении GitHub или через ИИ-агента вроде GitHub Copilot с использованием skill gh-stack.
Функцию уже опробовали несколько команд. Тим Ньюткенс, глава разработки Next.js в Vercel, рассказал, что команда использует стековые PR последние несколько месяцев, это помогает вносить более мелкие отдельные изменения при работе над крупными фичами и упрощает ревью. Джон Резиг, создатель jQuery, назвал превью «невероятным» и отметил, что слияние сразу пяти стековых PR в очередь мержа одной операцией сильно снимает трение в работе. Энди Мерримен, технический директор TED, объяснил, что рост продуктивности разработчиков благодаря ИИ создал новое узкое место, PR стали слишком большими для ревьюеров, и стековые PR решают эту проблему, разбивая изменения на упорядоченные по зависимостям куски. Майанк Сайни, инженер по связности в WHOOP, сравнил разницу с превращением стека из «инструмента поверх GitHub» в ощущение, что «это и есть GitHub».
Стек пул-реквестов раскатывается в публичном превью на все репозитории в течение ближайших дней. Поддержка очереди мержа (merge queue) для стеков будет раскатываться постепенно в течение ближайших недель, то есть на момент анонса покрывает функцию не полностью.
Ключевые факты
- GitHub запускает стек пул-реквестов (stacked pull requests) в публичном превью для всех репозиториев; раскатка идёт в течение ближайших дней.
- Крупное изменение разбивается на упорядоченную серию небольших PR-слоёв: каждый ревьюится и проверяется отдельно, а слить весь стек или его часть можно одной операцией.
- Нижние слои при частичном мерже уходят в main, а верхние остаются открытыми и автоматически перебазируются и перенацеливаются.
- Работать со стеками можно на github.com, через CLI-расширение (
gh extension install github/gh-stack), в мобильном приложении и через агента вроде GitHub Copilot со skill gh-stack. - Функцию уже используют команды Next.js в Vercel, TED и WHOOP; поддержка очереди мержа для стеков раскатывается постепенно в течение ближайших недель.
Почему это важно
Один гигантский пул-реквест, который никто не хочет ревьюить, обычная беда командной разработки: рецензент либо утопает в дифе, либо просматривает его формально. Стек решает это на уровне самого GitHub, а не через сторонний инструмент поверх него: большое изменение изначально режется на упорядоченные слои, каждый из которых остаётся маленьким и проверяемым, при этом весь механизм слияния, проверок и защиты веток работает без переделки процесса.
Кому это важно
В первую очередь, командам, которые двигают крупные фичи через много мелких коммитов и раньше вручную дробили их по разным веткам с постоянной перебазировкой. Отдельно показателен кейс TED: по словам технического директора Энди Мерримена, рост продуктивности разработчиков за счёт ИИ сам создал новое узкое место, PR стали слишком большими для ревьюеров, и стек нужен именно для того, чтобы это узкое место снять.
Как это применить
Начать можно через расширение GitHub CLI командой gh extension install github/gh-stack: создаётся ветка и PR для первого изменения, затем поверх добавляются новые ветки и PR, каждый нацеленный на слой под собой. Дальше со стеком можно работать на github.com, через CLI, в мобильном приложении GitHub или через ИИ-агента (например, GitHub Copilot) со skill gh-stack, карта стека в интерфейсе PR показывает, как ревьюируемый слой соотносится с остальной работой.
Можно ли доверять
Это официальный анонс в блоге GitHub с прямой ссылкой на документацию по стековым пул-реквестам, а цитаты в тексте принадлежат реальным узнаваемым фигурам с указанием должности: Тим Ньюткенс (глава разработки Next.js, Vercel), Джон Резиг (создатель jQuery), Энди Мерримен (технический директор TED), Майанк Сайни (инженер по связности, WHOOP). Источник первичный и проверяемый.
Риски и подводные камни
На момент анонса функция раскатывается в публичном превью постепенно, «в течение ближайших дней», то есть доступна не всем репозиториям сразу. Поддержка очереди мержа (merge queue) для стеков и вовсе растянута на «ближайшие недели», значит команды, которые уже используют merge queue, первое время могут не получить с ней полной интеграции стеков.
«Новый предпросмотр GitHub Stacked PRs, это нечто невероятное. Слить сразу пять стековых пул-реквестов в очередь мержа одним махом! Пятёрка с плюсом! Это снимает столько трения (а ещё CLI-инструменты gh и агентский skill сильно помогают)»
— Джон Резиг, создатель jQuery