GitHub вывел из превью механику связанных pull requests, которая позволяет разбивать крупные изменения на аккуратные слои и мержить их одной операцией.
GitHub вывел stacked pull requests из публичного превью в общий доступ. Если вы когда-нибудь пытались протолкнуть через ревью гигантский PR на пару тысяч строк, где смешаны рефакторинг, фикс бага и случайно заехавшая переделка стилей, вы понимаете, зачем это вообще придумали. Теперь большие изменения можно разложить на цепочку связанных pull requests, каждый из которых ревьюится отдельно и мержится в общий ствол.
Сама механика называется stack — это набор pull requests в одном репозитории, где каждый PR целится в ветку предыдущего. Получается упорядоченная цепочка, которая в итоге приземляется на одну базовую ветку, обычно на main. Вместо одного громоздкого дифа — набор мелких и сфокусированных. Каждый участник команды может одобрить свой слой, не продираясь через чужие правки.
Как это работает под капотом
Тут есть важный нюанс. Каждый pull request в стеке оценивается не по своей непосредственной ветке, а по базе всего стека. То есть если в цепочке main ← PR1 ← PR2 ← PR3 вы пытаетесь смержить PR, то проверки и правила защиты ветки применяются так, будто он целится в main. Средние слои получают ту же планку качества, что и нижний. Звучит логично, но поначалу ломает привычную картину мира у тех, кто привык к «а у меня отдельная ветка, отстаньте».
GitHub Actions при этом не требует переписывать воркфлоу. Если у вас настроен триггер на pull_request по main, он сработает для каждого PR в стеке автоматически. Метаданные стека доступны в выражениях через github.event.pull_request.stack, что позволяет оптимизировать CI и не гонять одни и те же проверки по кругу. Для больших проектов это экономит не только нервы, но и деньги на раннерах.
Ребейз, слияние и навигация
Когда стек становится нелинейным, в блоке слияния появляется кнопка Rebase stack. Если нижний PR мержится, ребейз остальных слоёв происходит автоматически. Вручную дёргать git rebase в терминале, молясь, что ничего не отвалится, теперь не обязательно. Стеки поддерживают все три метода слияния, и вся цепочка ложится в main как одна атомарная операция. Merge queue тоже полностью поддерживается — все PR из стека встают в очередь в правильном порядке.
Для локальной работы есть расширение gh stack в GitHub CLI. Оно создаёт ветки в правильном порядке зависимостей, поддерживает их в актуальном состоянии, пушит, создаёт и связывает pull requests, а также позволяет переключаться между слоями. При этом GitHub CLI не обязателен: базовые git-операции стандартные, и стек можно собрать прямо через веб-интерфейс. Если вы работаете с Jujutsu или Sapling, локальные ветки тоже можно заливать как стек — ограничений нет.
Отдельно стоит отметить, что поддержка стеков уже показала себя в цифрах. По данным самого GitHub, репозитории, которые пользовались стеками во время публичного превью, показали рост смерженного кода на 9% по сравнению с аналогичными проектами. Это не магия — просто изменения чаще доходят до main, потому что ревью перестаёт быть пыткой.
Что это значит для команд
Stacked pull requests — это попытка убрать боль, знакомую каждому тимлиду: огромные PR, которые висят неделями, потому что никто не хочет в них закапываться. Разбивая работу на слои, вы получаете быстрый фидбек и меньше конфликтов при слиянии. Единственный минус — порог входа. Тем, кто привык к простому «одна фича — одна ветка», придётся перестроить рабочий процесс и разобраться с навигацией по стеку. Но учитывая, что GitHub вложился в автоматизацию ребейза и merge queue, большая часть рутины уже спрятана под капот. Если хотите посмотреть, что там с деталями, официальные доки доступны на docs.github.com, а обсуждение — на github.com в разделе discussion.
Осталось дождаться, когда стеки начнут массово использовать не только крупные опенсорсные проекты, но и рядовые команды. Пока что выглядит так, будто GitHub наконец услышал мольбы разработчиков о нормальном ревью больших изменений.