GitHub stacked PR: небольшой diff не равен единице развёртывания

Dev
Просмотры 5

Три PR делают большой diff короче. Но зависимость верхнего PR от нижнего не позволяет автоматически выпускать его отдельно.

Объявление 6 октября

GitHub объявил общую доступность 6 октября 2026 года. Небольшие PR можно проверять отдельно и объединять вместе; функция доступна на всех планах github.com.

Стек входит в merge queue одной merge group. Метод merge commit создаёт отдельный commit для каждого PR. Единица тестирования отличается от единицы истории.

Редакционная схема: ревью PR → интеграция стека → развёртывание и rollback. Не снимок GitHub.
Редакционная схема: ревью PR → интеграция стека → развёртывание и rollback. Не снимок GitHub.

Запишите границы ревью

A добавляет функцию, B вызывает её в API, C создаёт UI. Укажите зависимости и base сравнения. Это рекомендация по процессу, не автоматическая гарантия продукта.

Читая только B, можно пропустить отсутствие проверки прав в A. Разделите ревью diff и проверку A+B+C, назначив ответственного за интеграцию.

Одобрение после rebase

GitHub сохраняет одобрения при rebase иначе неизменившегося стека после сдвига базы, даже при сбросе устаревших одобрений. Одобрение и текущий интегрированный результат — разные свидетельства.

Сохраните SHA до и после и проверенную merge group. Убедитесь, что тесты повторились и логи относятся к нужной комбинации: зелёной отметки мало.

Отделите merge от выпуска

Если функция и API должны выйти вместе, зафиксируйте зависимость в плане. Commit на каждый PR не гарантирует безопасный одиночный rollback для оставшихся вызовов.

Независимые исправления не требуют стека. Объединение может заставить всех ждать один задержавшийся тест; оцените операционные издержки.

GA и реальная доступность

GitHub планирует развёртывать auto-merge в ближайшие недели. Проверяйте видимые элементы репозитория, не предполагая одинаковую кнопку у всех сегодня.

Отзывы preview повлияли на навигацию и автоматизацию. Это интерес пользователей, не гарантия производительности. Измеряйте собственные ожидания ревью и ошибки интеграции.

Начните с малого стека

Выберите два явно зависимых PR, например функцию и вызывающий код. Запишите base, зависимость и тесты, согласуйте интеграцию и область rollback.

Сравните выигрыш времени с возможными новыми сбоями. Если обслуживание дороже, вернитесь к обычным PR. Важнее ясность ревью и выпуска, чем число diff.

Официальные источники

GitHub Changelog

Объявление 6 октября; проверено 8 октября 2026 года. Проверьте правила и доступные функции перед внедрением.