GitHub рассказала о подходе к работе с кодовыми агентами и ревью через стековые pull request (stacked PR). Компания предлагает разбивать крупные изменения на логически связанные слои, чтобы упростить проверку кода и сделать процесс более предсказуемым для людей и ИИ-агентов.
По данным GitHub со ссылкой на прогноз Gartner, кодовые агенты могут дать до 50% прироста продуктивности на всех этапах жизненного цикла разработки (SDLC) к 2028 году. Однако они унаследовали традиционную практику: генерировать один большой pull request с сотнями или тысячами изменений, что делает ревью тяжёлым и затягивает выпуск фич.
GitHub предлагает вместо одного крупного запроса формировать стек из нескольких небольших pull request. Каждый такой pull request решает одну задачу и зависит от предыдущего слоя. В результате, большой diff на 1 000+ строк заменяется на цепочку компактных и независимых для проверки шагов.
Процесс начинается с выбора базовой ветки стека. Все проверки CI и правила слияния оцениваются относительно этой базовой точки. Далее разработчики и агенты определяют ядро задачи и располагают его ближе к основанию стека, а зависимые изменения — выше.
GitHub приводит пример разбиения фичи на слои: данные, API, логика «прокладки» (wiring) и UX. Такой подход позволяет назначать разных ревьюеров на разные части: владельцы данных проверяют слой данных, владельцы интерфейса — только UI. Ревьюер не обязан держать в голове весь контекст сразу.
Для работы со стековыми pull request GitHub добавила нативную поддержку в интерфейс pull request и в командную строку через gh stack. В терминале доступны команды создания, разбиения и управления стеком, а в веб-интерфейсе отображается «карта стека» — навигация по всем pull request в цепочке.
GitHub подчёркивает, что кодовым агентам нужно «обучить» этот способ работы. Для этого используется набор навыков gh-stack skills, который объясняет агентам, как создавать и поддерживать стек от имени разработчиков, в том числе при строгой дисциплине: каждый агент отвечает за узкий участок работы и создаёт маленькие, одноцелевые pull request.
Отдельно отмечается роль CI. Каждый pull request в стеке прогоняет проверки относительно базовой ветки, и все слои должны проходить CI, прежде чем стек можно будет слить в основную ветку.
При ревью стек структурирует процесс: карта стека показывает путь от вершины к основанию, ревью читается сверху вниз по контексту, но проверяется снизу вверх, с нижнего слоя. GitHub приводит пример, как автоматический Copilot Code Review (CCR) ловит проблемы на первом слое, после чего изменения «поднимаются» по стеку.
Если одна из веток в стеке уходит вперёд и расходится с остальными, GitHub явно помечает это сообщением о необходимости выполнить rebase и блокирует слияние всего стека. В интерфейсе появляется кнопка Rebase stack, но GitHub предупреждает о нюансах: веб‑rebase выполняется на серверах компании, меняет автора коммитов и оставляет их неподписанными, что может нарушить политики ветки.
В качестве более безопасного варианта GitHub советует использовать gh stack rebase в терминале, чтобы выполнить каскадный rebase локально с текущей Git-конфигурацией, а затем отправить изменения через gh stack push. После этого командой gh stack sync синхронизируется состояние всех веток и pull request с GitHub.
После rebase и синхронизации все проверки CI проходят заново, стек выстраивается в прямую, готовую к слиянию цепочку. GitHub подчёркивает, что изменения «распространяются» по стеку вверх без ручной правки верхних слоёв, что сокращает рутину и уменьшает риск конфликтов.
Материал также отсылает к другим техническим публикациям GitHub: о модернизации старого кода с помощью стековых сессий и pull request в приложении GitHub Copilot, о высокопроизводительной обработке байтов при поиске кода и об оптимизации работы Dependabot через группировку обновлений и снижение частоты запросов.
Источник: блог GitHub.
