Pull requests без боли. GitHub представил Stacked PRs — новый способ не сойти с ума во время проверки кода

GitHub решил упростить жизнь разработчикам, которые устали продираться через огромные pull request с десятками файлов и длинными цепочками зависимостей. Платформа представила Stacked PRs , новый механизм для работы с взаимосвязанными запросами на слияние, который должен ускорить ревью и сделать крупные изменения более управляемыми.

Функция уже доступна в формате private preview. Stacked PRs позволяют строить цепочку pull request, где каждый следующий запрос опирается на предыдущий и образует стек. Каждый элемент такой цепочки можно проверять и сливать отдельно, если все pull request ниже по стеку уже попали в основную ветку. При желании GitHub позволяет объединить и весь стек целиком.

Главный смысл нововведения сводится к тому, чтобы разработчики чаще разбивали большую задачу на небольшие и логически завершенные части. Такой подход упрощает проверку кода, потому что ревьюеру не приходится разбираться сразу в большом наборе изменений. Документация GitHub советует строить стек так, чтобы каждая ветка представляла отдельный фрагмент работы, который можно оценить независимо от остальных.

Проблема, которую GitHub пытается решить, давно знакома командам разработки. Программисты редко хотят останавливать работу и ждать, пока маленький фрагмент кода проверят и вольют в main. Если новые изменения зависят от еще не принятого кода, разработка продолжается в отдельной ветке до завершения всей функции. В итоге на ревью уходит один большой pull request, где изменения размазаны по множеству файлов и проверить их быстро уже трудно.

Не спрашивайте почему мы в MAX. Мы и сами не гордимся

Для GitHub подход со стеком стал новинкой, хотя сама идея далеко не новая. В других системах управления кодом и ревью похожий механизм известен как stacked diffs. Один из самых известных примеров появился еще в 2007 году, когда в Facebook* создали инструмент Differential . Позднее он вошел в состав набора Phabricator, который выпустили как проект с открытым исходным кодом в 2011 году. Разработка открытой версии Phabricator остановилась в 2021-м, но форк Phorge до сих пор активно поддерживают.

Рабочий процесс со Stacked PRs заметно отличается от привычной схемы. Нижний pull request в стеке обычно строят от основной ветки, а не от отдельной промежуточной ветки. Бывший инженер Facebook Джексон Габбард ранее писал , что разработчики, которые привыкли к stacked diff в Phabricator, обычно очень ценят такой формат и стараются внедрить его на новом месте работы.

Обсуждение на Hacker News оказалось в целом благожелательным, хотя часть разработчиков усомнилась, нужен ли для такого подхода отдельный интерфейс командной строки. Один из участников заметил , что в Git за последние годы уже появились возможности, которые позволяют выстроить подобный процесс нативно. Речь идет о новом расширении GitHub gh stack. В самой компании подчеркивают, что CLI не обязателен: создавать stacked PR можно и через обычный интерфейс.

GitHub связывает запуск функции не только с удобством команд, но и с ростом роли ИИ в разработке. В компании считают, что узким местом уже стало не написание кода, а его проверка. По словам инженера Sameen Karim, стеки помогают снять часть нагрузки именно на этапе ревью, а CLI заодно проектировали с расчетом на работу ИИ-агентов.