Перевірити й змерджити PR

Цей посібник показує, як перевірити й змерджити pull request.

Відкрити верстак PR

Перейдіть до Pull requests на бічній панелі
Виберіть PR зі списку

PR відкривається як верстак із вкладками, а не як окрема сторінка. Типово відкриваються п’ять вкладок у такому порядку: Огляд, Різниця, Керування кодом, Чат і Дії (перевірки CI, згруповані за робочим процесом). Рев’ю — хід конвеєра рев’ю, а потім артефакт, який він опублікував, із панеллю знахідок — навмисно не входить до їхнього числа: у PR немає рев’ю, доки хтось його не попросить, тож його відкриває Запитати AI. Термінал, редактор одного файлу, вбудований code-server і браузер у застосунку відкриваються на вимогу; вкладки попереднього перегляду розгортання додаються автоматично, щойно в PR буде виявлено URL попереднього перегляду. Розташування ваших вкладок запам’ятовується для кожного PR.

Вкладка «Огляд» містить метадані PR (автор, гілка, мітки, призначені, реакції, коміти, стан перевірок) і рядок дій: оновити, Рев’ю, Злити, відкрити в IDE і меню переповнення ⋯.

Прочитати diff

Відкрийте вкладку Різниця, щоб побачити весь diff PR одразу, з деревом файлів для переходу між файлами.

Кнопка налаштувань на панелі інструментів diff перемикає розділений (поряд) та об’єднаний вигляд, а також вмикає перенесення рядків і лігатури шрифту коду.
Замість заголовків блоку @@ з’являються елементи Show N lines / Show end of file, які за натисканням підставляють навколишній контекст.
Натискайте j / k, щоб переходити між файлами, c — щоб згорнути чи розгорнути файл у фокусі, t — щоб повернути бічну панель до дерева файлів, і ⌘F — щоб шукати по всьому diff (Enter / Shift+Enter перебирають збіги).
Натисніть v, щоб позначити файл у фокусі як переглянутий, — і курсор перейде до наступного файлу. На GitHub стан «переглянуто» зберігається на хості коду, тож він супроводжує вас між клієнтами; у GitLab і Bitbucket такого API немає, тому там він запам’ятовується лише на цьому пристрої.

Перетягування мишею в області коду виділяє текст аж до точного стовпця, а ⌘C копіює необроблений код, а не відрендерені маркери diff.

Залишити коментарі в рядку

Торкніться жолоба рядка коду, щоб відкрити форму коментаря, прив’язану до цього рядка, або скористайтеся кнопкою + в заголовку файлу, щоб залишити коментар до всього файлу
Напишіть свій відгук у Markdown
Надішліть

На GitHub і GitLab форма пропонує два варіанти надсилання: Додати окремий коментар публікує одразу, а Почати рев’ю / Додати до рев’ю ставить коментар у чергу до відкладеного рев’ю, яке вийде разом із Схвалити, Запросити зміни або Коментар. У Bitbucket пакетного відкладеного рев’ю немає, тож там кожне надсилання публікується одразу. Негайна публікація показує стан очікування, доки хост коду її не підтвердить, після чого перемикається на «синхронізовано». Якщо публікація не вдалася, обговорення позначено помилкою, і воно пропонує повторити.

Чернеткою є лише тіло рев’ю: через мить після того, як ви припините друкувати, воно зберігається на сервері за ключем (owner, repo, номер PR), тож переживає перезавантаження й супроводжує вас між настільним клієнтом і вебклієнтами.

Надіслати рев’ю

Натисніть Рев’ю в рядку дій на вкладці «Огляд» (його приховано для ваших власних PR, а також для закритого чи злитого PR)
Напишіть тіло рев’ю. Можна прикріпити зображення, вставити емодзі чи GIF і перемикатися між написанням і попереднім переглядом
Натисніть Запросити зміни, Коментар або Схвалити

Вердикт і є кнопкою — окремого вибору вердикту немає. Після Схвалити або Запросити зміни кнопка перейменовується на Схвалено чи Запитані зміни, а чернетку тіла очищено. Вердикт Коментар залишає на кнопці підпис Рев’ю.

Злити

Кнопка Злити з’являється, коли ви маєте право на запис, а PR відкритий і не є чернеткою. Її колір — сигнал готовності, обчислений з потрібних схвалень і стану перевірок (готово / в очікуванні / заблоковано); він має лише рекомендаційний характер. Стан рев’ю ніколи не вимикає кнопку: правила забезпечує власний захист гілки на хості коду.

Натисніть Злити, щоб відкрити висувну панель злиття
Виберіть спосіб злиття: squash, merge commit або rebase (типово — squash). У Bitbucket немає справжнього злиття через rebase, тож rebase зводиться до його стратегії fast-forward і зазнає невдачі на розбіжній гілці
Для squash і merge commit відредагуйте попередньо заповнені заголовок і опис коміту. Rebase не приймає жодного з них і ховає обидва поля
Прочитайте панель попереджень — у ній названо перевірки, що не проходять, і рев’ю, що очікуються, але вона вас не блокує
Натисніть кнопку злиття на цій панелі, щоб підтвердити

Злиття незворотне: воно надсилає коміти на хост коду, тож замість запису до стеку скасування отримує крок підтвердження. Після цього кеш PR анулюється, його статус змінюється на Злито, і спрацьовує подія PullRequestStatusChanged зі статусом merged. Ця подія звільняє ефемерне робоче дерево «відкрити в редакторі» й запускає два вбудовані конвеєри: Stale repository cleanup, який вилучає застарілі робочі дерева та теки розмов цього PR, і Release notes, який готує чернетку запису до журналу змін.

Передати PR агентам-рев’юерам

Меню переповнення ⋯ на вкладці «Огляд» містить пункт Запитати AI, який запускає вбудований конвеєр pr_review для цього PR. Воно з’являється лише поки PR відкрито. Про те, що робить конвеєр і як опублікувати його знахідки, дивіться Використовувати ШІ-перевірку, а про детерміновану модель когорт і осей — Обчислення перевірки.

Перевірити зовнішній PR

Control Center також імпортує PR, відкриті людьми поза застосунком. Описаний вище процес рев’ю — той самий. Зовнішні PR виявляє служба опитування PR.