GitHub объявил о полноценном запуске stacked pull requests — связанных пул‑реквестов, которые позволяют разбивать крупные изменения на несколько небольших и зависимых друг от друга PR. Каждый из них можно отдельно просматривать, обсуждать и проверять, сохраняя при этом контекст всей цепочки.
Вместе с переходом функции в общий доступ GitHub доработал слияние, ребейз, навигацию по стеку и автоматизацию.
Как работают связанные пул‑реквесты
Вместо одного большого PR изменения можно разбить на последовательность небольших. Первый пул‑реквест обычно направлен в main, следующий — в ветку первого, третий — в ветку второго и так далее.
Например:
main ← PR с базовой логикой ← PR с API ← PR с интерфейсом
При этом каждый PR показывает изменения только своего уровня. Разработчик может продолжать работу над следующей частью задачи, не дожидаясь слияния предыдущей, а ревьюеру не приходится разбирать один большой diff.
По данным GitHub, с начала публичного тестирования в репозиториях, использующих стеки, объём слитого кода вырос на 9% по сравнению с сопоставимыми репозиториями. Среди 1% наиболее активных репозиториев стеки используют уже более двух третей; GitHub также отмечает у них сокращение времени до слияния примерно на 5%.
Ребейз больше не должен сбрасывать согласования
Одно из заметных изменений касается Rebase stack.
Если основная ветка, например main, ушла вперёд и стек пришлось перебазировать без изменения самого кода, ранее это могло привести к сбросу уже полученных одобрений. Теперь GitHub сохраняет их даже в репозиториях, где включено автоматическое удаление устаревших согласований.
Кроме того, при ребейзе GitHub создаёт подписанные замещающие коммиты и сохраняет исходное авторство. Автоматический ребейз после частичного слияния стека также подписывает новые коммиты, когда этого требуют правила ветки или исходные коммиты уже были подписаны.
Изменилось слияние стеков
Права на обход правил репозитория теперь распространяются и на стеки. Пользователь с соответствующими разрешениями может применить их к нижнему ещё не слитому PR.
Для репозиториев с очередью слияния весь выбранный участок стека теперь попадает в неё как единая группа. При использовании обычных merge‑коммитов GitHub при этом создаёт отдельный merge‑коммит для каждого пул‑реквеста, а не один общий на всю группу.
Изменилось и поведение стеков, построенных друг на друге. Если базовая ветка такого стека удаляется после слияния предыдущей цепочки, GitHub автоматически переназначает базу вместо закрытия нижнего PR.
В ближайшие недели также появится автоматическое слияние стеков. Можно будет выбрать несколько связанных PR, после чего GitHub сольёт их вместе, как только все проверки и требования репозитория будут выполнены.
Стек теперь лучше виден в интерфейсе
Информация о стеке постоянно отображается в заголовке страницы пул‑реквеста. Увидеть принадлежность PR к стеку можно и в общем списке пул‑реквестов.
Для перехода между уровнями добавили сочетания Shift + J и Shift + K.
GitHub также начал фиксировать в истории PR события добавления и удаления из стека. В webhook pull_request появился новый тип события stacked, который срабатывает при добавлении пул‑реквеста в стек.
Что изменилось в GitHub CLI
Для работы со стеками из командной строки используется расширение gh stack. Оно умеет создавать последовательность зависимых веток и PR, отправлять весь стек в GitHub и выполнять каскадный ребейз.
В новой версии расширение также поддерживает Git worktree. GitHub доработал и операции инициализации, переключения между ветками и навигации по стеку.
Stacked pull requests уже доступны на всех тарифах github.com. Поддержку также планируют добавить в одну из следующих версий GitHub Enterprise Server.
Расписание бесплатных IT‑вебинаров на октябрь уже доступно в календаре.
