Stacked prs: как Github упрощает работу с большими пулл-реквестами

Знаешь, что бесит больше всего в разработке? Когда ты неделю пишешь фичу на 2000 строк, а ревьювер смотрит на это и говорит: «Давай разберёмся в следующий понедельник». И ты понимаешь — он прав. Большие пулл-рексты (PR — аббревиатура от Pull Request, запрос на слияние кода в основную ветку) — это как пытаться съесть слона целиком: можно, но подавишься.

GitHub недавно представил решение под названием Stacked PRs. Это нативная поддержка цепочек пулл-реквестов прямо в интерфейсе GitHub. Разработчики могут разбить большое изменение на несколько маленьких PR, которые «стоят» друг на друге, как блины в стопке. Каждый PR — это отдельный слой, который можно ревьюить независимо, а мерджить (merge — слияние) всё вместе.

Что такое stacked prs

Представь: пишешь новую фичу авторизации. Она включает три части: бэкенд для проверки токенов, API-роуты и фронтенд для формы логина. Раньше ты бы сделал один большой PR на 50 файлов. Со Stacked PRs можешь создать три пулл-реквеста, которые идут друг за другом:

СТРУКТУРА STACKED PRS
──────────────────────
main ──▶ auth-backend ──▶ auth-api ──▶ auth-frontend
          (слой 1)        (слой 2)       (слой 3)

Каждый PR целится в ветку ниже, а не в main напрямую.

Первый PR (auth-backend) мерджится в main. Второй (auth-api) целится в auth-backend и после мерджа первого автоматически перебазируется на main. Третий — в auth_api, и так далее. В итоге все три сливаются в main напрямую.

Ветка (branch — независимая линия разработки) представляет собой изолированное пространство для работы над кодом проекта.

GitHub теперь понимает эту структуру. В интерфейсе появляется карта стека — можно кликнуть на любой PR и увидеть что выше и что ниже в цепочке.

Зачем это нужно

Большие PR — это реальная проблема:

• Ревьювер теряет контекст при просорении diff более 2000 строк кода.
• Конфликты при rebase становятся причиной значительных задержек.
• Задержки ревью приводят к неделям ожидания фичи.

Stacked PRs решает это через декомпозицию задач: бэкенд логика отдельно API отдельно UI отдельно.

Как это работает

CLI даёт больше контроля поэтому начинаем с него:

gh extension install github/gh-stack

Добавляешь alias для удобства:

gh stack alias

Теперь `gs` твой короткий путь к командам.

Создаёшь первый слой:

gs init auth-layer
## ... пишешь код коммитишь ...

Commit сохраняет изменения локально чтобы затем запушить их удаленно через push операцию.

Добавляешь следующие слои:

gs add api-routes
## ... пишешь код коммитишь ...

gs add frontend
## ... пишешь код коммитишь ...

Весь стек лежит локально в разных ветках repo хранилище кода проекта где пушишь всё разом:

gs push

Push отправляет локальные изменения удаленный сервер чтобы создать pull request через submit командную строку или веб интерфейс GitHub где открывается страница цепочкой pull request ревьювер видит карту может кликнуть любой слой посмотреть только его diff когда готов мерджить одна кнопка мерджит весь стек или можно мерджить по одному через merge queue очередь автоматического слияния проверками

Нюансы которые важно знать

Stacked PRs пока приватном превью нужно записаться waitlist лист ожидания список людей ждущих доступа функции означает что массово использовать пока не получится, но можно попробовать понять нужно ли оно тебе CLI требует привычки команды gs add gs push gs submit новый синтаксис придётся потратить вечер чтобы мышечной памяти muscle memory автоматическое действие закрепилось AI агенты программы автокодеры которые пишут код сами Cursor Claude Code тоже умеют добавить навык через npx skills add github/gh-stack полезно если работаешь автономными кодерами

РАБОЧИЙ ПРОЦЕСС С GITHUB STACKED PRS
─────────────────────────────────────

    ┌─────────────┐     ┌─────────────┐     ┌─────────────┐
    │   gs init   │────▶│    код      │────▶│   commit    │
    └─────────────┘     └─────────────┘     └─────────────┘

    ┌─────────────┐     ┌─────────────┐     ┌─────────────┐
    │   gs add    │────▶│    код      │────▶│   commit    │
    └─────────────┘     └─────────────┘     └─────────────┘

           │                         │
           ▼                         ▼

    ┌──────────────────────────────────────────────────┐
    │                  gs push                         │
    │         [ветки отправляются на сервер]           │
    └──────────────────────────────────────────────────┘

           │
           ▼

    ┌──────────────────────────────────────────────────┐
    │                 gs submit                        │
    │         [PR создаётся через интерфейс]           │
    └──────────────────────────────────────────────────┘

           │
           ▼

         МЕРДЖ ЧЕРЕЗ UI ИЛИ MERGE QUEUE

ТИПИЧНЫЙ РАЗМЕР ПР:
───────────────────

Традиционный подход:      Stacked PRs:
┌───────────────────┐     ┌───┐ ┌───┐ ┌───┐ 
│                   │     │ 1 │→│ 2 │→│ 3 │
│   Один ПР         │     └───┘ └───┘ └──━┘ 
│   50 файлов       │       ↓   ↓   ↓   
│   2000+ строк     │      review review review  
└───────────────────┘      ~10min ~10min ~10min  
~1 час ревью               Вместо ~1 часа = ~30 минут  

Стоит ли пробовать

Если регулярно пишешь фичи сталкиваешься задержками конфликтами при мердже Stacked PRs может серьёзно упростить жизнь Идея не новая Linux сообществе называется patch series серия изменений кода идущих друг за другом, но то что GitHub сделал это нативно без костылей большой шаг Минус ждёшь доступ Плюс когда выкатят будет интеграция прямо UI без дополнительных инструментов Лично мне нравится подход Больше не нужно просить ревьювера посмотреть «вот этот кусок, а потом вот тот» Каждый сам по себе правильно Документация доступна по адресу https://github.github.com/gh-stack/ gh stack CLI доступен https://github.com/github/gh-stack

Ссылки

• GitHub Stacked PRs — официальная документация по Stacked PRs