GitHub перевів стековані pull requests у режим публічного попереднього перегляду (public preview), дозволяючи розробникам розділяти великі зміни на ланцюжок залежних PR, які можна переглядати та зливати незалежно.

Чому ця функція важлива

Один монолітний PR часто перетворюється на місячний процес перегляду, коли рев'юери змушені продиратися крізь непов'язаний код. Коли базова гілка змінюється, такі масивні зміни стають схильними до конфліктів злиття, що затримує релізи. Стековані PR вирішують обидві проблеми, перетворюючи один великий набір змін на серію менших, цілеспрямованих змін, кожна з яких базується на попередній.

Як це працює

Створіть перший PR до основної гілки, потім зробіть наступний PR на основі першого, третій — на основі другого і так далі. GitHub автоматично відстежує зв'язки: якщо ви вносите зміни в базовий PR, залежні PR оновлюються відповідно до нового стану. Рев'юери можуть схвалити весь стек одним кліком або підтвердити окремі рівні.

  • Огляди залишаються в межах вузького обсягу, що прискорює отримання фідбеку.
  • Кількість конфліктів зменшується, оскільки кожен PR стосується лише коду, доданого на його власному рівні.
  • Інтерфейс відображає ієрархію стека, а GitHub CLI пропонує команду в один рядок для створення серії стекованих PR.
gh pr create --title Feature A --base main
gh pr create --title Feature B --base feature-a
gh pr create --title Feature C --base feature-b

Приклад командного рядка створює три пов'язані PR, кожен з яких залежить від попереднього. Такий самий робочий процес доступний через вебінтерфейс, де ви можете змінювати порядок або видаляти PR зі стека, не порушуючи роботу інших.

Кому це принесе користь

Великі продуктові команди та мейнтайнери open-source проектів можуть випускати інкрементальну роботу, не змушуючи рев'юерів розбиратися з непов'язаними змінами. Менеджери релізів отримують чіткішу картину того, що готове до випуску, оскільки кожен рівень стека можна зливати за власним графіком.

Нюанси, які варто врахувати

Функція все ще перебуває на стадії preview, тому вона може змінитися до повного релізу. Командам потрібно буде виробити нові звички щодо розгалуження (branching) і вони можуть зіткнутися з граничними випадками під час ребейзингу стека, який уже був частково злитий. Документація все ще доповнюється, тому перші користувачі можуть витрачати додатковий час на вивчення підказок інтерфейсу.

На що звернути увагу далі

GitHub, ймовірно, запровадить тіснішу інтеграцію з code-owners та інструментами автоматизації, а також може надати метрики щодо зменшення кількості конфліктів. Стежте за сторінкою оголошення про preview, щоб дізнатися про терміни виходу GA (загальної доступності).

Підсумок: Стековані pull requests дають розробникам практичний спосіб приборкати масивні зміни, перетворюючи один важкий через конфлікти PR на керовану, зручну для перегляду послідовність. Якщо ваш робочий процес страждає від тривалих переглядів та проблем із злиттям, ця попередня версія варта випробування.