GitHub перевёл стековые pull request в статус общей доступности. Функция предназначена для крупных изменений, которые удобнее разделить на несколько небольших зависимых запросов на слияние. Каждый элемент стека можно отправить на ревью отдельно, а затем объединить изменения в заданном порядке.
Стековые pull request доступны на всех тарифах GitHub.com. Для GitHub Enterprise Server компания обещает включить функцию в одном из будущих выпусков, но конкретную версию и дату пока не называет.
Как устроены стековые pull request
При обычной работе большую задачу часто оформляют одним pull request. Такой подход подходит для небольших изменений, но усложняет ревью, если в запросе одновременно есть изменения в нескольких компонентах, подготовка инфраструктуры и основной код.
Стек позволяет разбить такую работу на последовательные части. Например, первый pull request может содержать базовые изменения, второй — код, который от них зависит, а третий — интеграцию или тесты. Запросы остаются связанными, поэтому их можно рассматривать как единую цепочку, не смешивая все изменения в одном наборе.
В интерфейсе GitHub отображаются ветви стека, их статусы и переходы между связанными pull request. Это избавляет команду от необходимости вручную поддерживать список зависимостей и искать предыдущие запросы по ссылкам.
При этом стек не делает связанные изменения независимыми. Если следующий запрос опирается на предыдущий, задержка или доработка ранней части может повлиять на всю последовательность. GitHub в объявлении не раскрывает все сценарии работы с конфликтами, изменением уже проверенного запроса и перестановкой элементов. Такие детали команде нужно сверять с документацией GitHub по pull request.
Какие результаты приводит GitHub
В объявлении GitHub ссылается на данные периода публичного предварительного доступа. По утверждению компании, в репозиториях, использующих стеки, объём слитого кода оказался на 9% выше, чем у сопоставимых репозиториев.
GitHub также сообщает, что стековые pull request используют более двух третей репозиториев из верхнего 1% по активности. В этой группе, по данным компании, время до слияния улучшилось на 5%.
Эти показатели нельзя трактовать как независимое доказательство эффективности функции. В публикации не описаны методика подбора сопоставимых репозиториев, продолжительность измерений и другие параметры сравнения. Кроме того, связь между использованием стеков и улучшением метрик не доказывает, что причиной изменений стала именно эта функция: на скорость ревью влияют размер команды, тип проекта, правила согласования и качество автоматических проверок.
Для команд это означает, что заявленные проценты лучше использовать как повод для собственного эксперимента, а не как обещание гарантированного ускорения.
Что изменилось после предварительного доступа
GitHub говорит, что при переходе к общей доступности улучшил создание, проверку и слияние стеков. Полного списка изменений в исходном сообщении нет, поэтому по нему нельзя точно определить, какие элементы интерфейса появились именно в новой версии, а какие были доступны во время публичного предварительного доступа.
Компания также приводит отзывы пользователей. Чарли Марш, основатель Astral, положительно оценил опыт слияния через стековые pull request. Инженер Comcast Дэвид Мостоллер отметил, что отображение ветвей, статусов и переходов в интерфейсе упрощает работу с большим числом зависимых запросов.
Это отзывы, опубликованные самой GitHub, а не результаты независимого сравнения. Они показывают возможный сценарий использования, но не подтверждают одинаковый эффект для всех команд и типов разработки.
Что это меняет для команд
Главное практическое изменение — возможность использовать дробную подачу связанных изменений без стороннего инструмента или отдельного процесса отслеживания зависимостей в интерфейсе GitHub.com. Подход может быть полезен командам, которые регулярно разбивают большие задачи на последовательные части и хотят начинать ревью до завершения всей работы.
Перед внедрением стоит выбрать одну задачу, которую действительно можно разделить на несколько зависимых этапов. Для сравнения с прежним процессом полезно зафиксировать:
- время от открытия первого pull request до слияния последнего;
- количество циклов ревью;
- число изменений, возвращённых автору на доработку;
- время ожидания между последовательными запросами;
- частоту конфликтов после изменений в ранних элементах стека.
Сравнивать лучше похожие задачи, а не отдельный удачный пример с усреднёнными показателями команды. Если ранняя часть стека часто меняется, последующие запросы могут потребовать повторной проверки, и ожидаемое ускорение исчезнет.
Командам на GitHub Enterprise Server также нужно отдельно проверить доступность функции в своей среде. Общий запуск на GitHub.com не означает, что возможность уже появилась в установленной корпоративной версии. За обновлениями и документацией Enterprise Server можно следить в разделе официальных заметок о выпусках.
Пока GitHub не публикует дату релиза для Enterprise Server и подробную методику расчёта заявленных метрик. Поэтому перед переходом стоит проверить поддержку стеков в конкретной версии платформы, определить правила ревью для зависимых запросов и провести ограниченный тест на типичной для команды задаче. Подробное объявление о статусе функции опубликовано в GitHub Changelog.
