Как разбить сгенерированный ИИ пул-реквест на стек: инструкция по GitHub Stack

Вспомни последний крупный фич-реквест вашей команды. Он прилетел одним гигантским диффом? Или вы вручную вели цепочку мелких веток, синхронизируя и разруливая конфликты? Раньше это были два плохих варианта: один неудобно ревьюить, другой — тяжело поддерживать.

Теперь в игру вступают агенты кодинга. Gartner прогнозирует рост продуктивности на 50% на каждом этапе жизненного цикла ПО к 2028 году. Но агенты не снимают вопрос структуры пул-реквеста — они его обостряют. Их дефолт — решить всю задачу за один заход и выдать один огромный дифф, потому что так написано большинство кода в их обучающей выборке.

Пока генерация кода дешевеет, ревью остаётся бутылочным горлышком. GitHub это понимает и опубликовал плейбук: как разбить один сгенерированный ИИ-пул-реквест на стек нормальных. Разбираем его на практике.

Дефолт: один огромный дифф

Пример из статьи — добавление поиска товаров в shopping assistant. Вы даёте агенту промпт, через несколько минут он возвращает пул-реквест, в котором всё сразу: новая модель данных и сиды, API-роут с валидацией, клиентская обвязка, UI, состояния fallback и ошибок. Итого — 1721 строка.

«Изменено 1721 строк!! Описание не очень помогает. Посмотрю позже» — вот что чувствует ревьюер, открывая такой дифф.

Дальше знакомый каскад: PR висит, потому что никто не хочет его ревьюить. Ревьюеры теряют контекст, качество фидбека падает. Мердж замедляется. Фича в итоге либо вкатывается недоревьюенной, либо умирает в стопке «потом».

Решение: стеки пул-реквестов

Stacked pull requests — это другая структура поставки. Вместо одного PR, закрывающего всю задачу, вы разбиваете фичу на логические слои, выстраиваете цепочку зависимостей и отправляете стек маленьких, сфокусированных и независимо ревьюабельных PR.

Вот как выглядит стек из примера GitHub:

Каждый слой — одна задача, которая помещается в голове ревьюера. Контекст перетекает из нижнего PR в верхний. Бонус: разные люди могут ревьюить разные слои. Владелец данных смотрит данные, владелец UI — UI. Никому не нужно держать в голове все 1700 строк.

Команды, которые делают это возможным

Настройка занимает две команды, и вторая — самое интересное:

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

Работа со стеком по слоям: инициализируете стек командой gh init stack — первая ветка с базой main. Добавляете каждый следующий слой через gh stack add. Прогоняете проверки и коммитите только зелёный код. Когда слои готовы, gh stack push и gh stack submit открывают все PR разом.

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

Честный размен

Теперь правда. Стек превращает огромный неревьюабельный дифф в мелкую хозяйственную работу. Но у этой работы есть зубы.

Когда изменение попадает в нижнюю ветку не в свою очередь, GitHub помечает весь стек: «Some branches in this stack have diverged and must be rebased» — и блокирует мердж. Есть кнопка Rebase stack, она работает, но выполняется на серверах GitHub. Это означает, что коммиттер перезапишется на того, кто нажал кнопку, коммиты станут неподписанными, а если в вашем branch protection требуются подписанные коммиты — этот клик тихо всё ломает.

Безопасная альтернатива: gh stack rebase локально, с вашим Git-конфигом, затем gh stack push и gh stack sync, чтобы изменения распространились вверх по стеку. Последняя команда суть всей схемы: одно изменение внизу проходит наверх без ручных правок в двух, трёх, четырёх слоях.

Что вынести маленькой команде

Вы меняете ревью на 1721 строку на ритуал ребейза с понятными командами. Для маленькой команды это выгодный обмен: ревью — дефицитный ресурс, и стек его защищает. Но работает это только если структура стала привычкой, а не геройским поступком. Агенты делают декомпозицию дешевле, но и пропустить её — проще.

Если агент способен написать 1700 строк за минуты, единственный вопрос — поспевает ли ваш процесс ревью. Стек на этот вопрос отвечает структурой, а не надеждой на сознательность.