# Рев'ю pull request очима PM: коментарі, пропозиції, approve

> Що продакт перевіряє в pull request, а що лишає інженерам, як коментувати рядок, пропонувати зміни з точним формулюванням, вирішувати, коли схвалити pull request, а коли попросити змін, і писати коментарі до рев'ю, які приємно отримувати.

- Курс: [Git і GitHub для продактів](https://productovi.com/uk/courses/git-for-product.md)
- Модуль: Pull requests
- Урок 8/15, ~42 хв
- Джерело: https://productovi.com/uk/courses/git-for-product/reviewing-as-a-pm

## Що продакт перевіряє в pull request

**Alex Tutor:** День рев'ю #134, і від продуктової команди Котокорму рецензуєш саме ти. До вечора ти або схвалиш pull request, або попросиш змін. Перш ніж відкривати бодай один файл: що саме ти перевіряєш?

**Sofia:** Не код. Мабуть, поведінку?

**Alex Tutor:** Зміну такою, якою її зустріне клієнт. Чи робить вона те, про що просило issue? Чи добре читаються тексти? Чи не робить вона чогось, про що issue не просило? Що буде у випадках, які ніхто не записав?

![Жінка пробує оформити замовлення на телефоні, як покупець; позаду розробник відкрив панель і роздивляється шестерні всередині механізму.](https://productovi.com/courses/git-for-product/inline/reviewing-as-a-pm-illustration-2.webp)

**Daniel:** А код лиши інженерам: назви, структуру, швидкодію, який підхід мені варто було обрати. Цим займається Oscar. Він схвалив зміни годину тому.

```text
Рев'ю на #134 на цей момент
- [Approved] Oscar: Approved these changes: код у порядку
```

**Sofia:** Тобто моє рев'ю відповідає на питання «чи це правильна зміна для клієнтів?», а не «чи це добрий код?»

**Alex Tutor:** Саме так. А якщо щось у коді здається тобі дивним, постав питання. Не давай вказівок щодо того, чого не можеш оцінити. Увесь чеклист на одній сторінці є в нашому дописі про [рев'ю pull request](/uk/blog/how-to-review-a-pull-request).

> **Вправа:** Pull request #134 виправляє issue #131: кнопка оформлення замовлення лишається сірою після того, як клієнт редагує кошик. Код переглядає Oscar, а Sofia продуктова рев'юерка. Що з цього входить у її рев'ю? Познач усе, що підходить.

## Почни з preview

**Alex Tutor:** Почни там, де почнуть клієнти: з preview. Спершу пройди кроки з «How to test» від Daniel, а потім спробуй те, чого він не записав.

**Sofia:** Кроки з першого по третій на телефоні працюють. Змінюю кількість, кнопка лишається зеленою. Прибираю все, вона сіріє, і з'являється підказка: «Cart is empty. Add items to checkout.»

**Alex Tutor:** Тепер **граничні випадки** (edge cases): шляхи поза щасливим сценарієм. Що ще клієнт може зробити з кошиком?

![Широка дорога веде до крамниці, від неї відходять вузькі стежки й об'їзди; людина з ліхтариком досліджує одну з бічних стежок.](https://productovi.com/courses/git-for-product/inline/reviewing-as-a-pm-illustration-3.webp)

*Покупці рідко йдуть точно тими кроками, що в описі.*

**Sofia:** Прибирати товари по одному кнопкою «мінус», а не смітничком. Застосувати промокод, а потім змінити кількість. Відкрити кошик у двох вкладках і редагувати в обох.

**Daniel:** Дві вкладки це підступно. Мені подобається.

**Sofia:** Усе працює. Бентежить лише підказка: «Add items to checkout» читається як повідомлення про помилку.

> **Вправа:** #134 виправляє кнопку оформлення після змін у кошику. Кроки з «How to test» від Daniel: змінити кількість (кнопка лишається зеленою), потім спорожнити кошик (вона сіріє й показує підказку). Що з цього є граничним випадком, який варто спробувати на preview, окрім цих кроків?

## Коментар до рядка в pull request

**Alex Tutor:** Тепер `Files changed`. Читати кожен файл не обов'язково. Станом на 2026 рік у кожного файлу є позначка `Viewed` («переглянуто»): відміть ті, що вже переглянуто або лишено іншим, і вони згорнуться.

**Sofia:** Компонент і тест це до Oscar. Лишаються `copy/cart.json` і `styles/checkout.css`.

**Alex Tutor:** Наведи курсор на рядок у diff, і з'явиться синій `+`. Натисни його або протягни через кілька рядків, і просто під рядком відкриється поле коментаря.

**Alex Tutor:** У поля дві кнопки. `Add single comment` («додати окремий коментар») публікує одразу. `Start a review` («почати рев'ю») зберігає коментар як чернетку, тож можна додати ще й надіслати все разом із вердиктом.

**Daniel:** Будь ласка, збирай усе разом. П'ять окремих коментарів це п'ять сповіщень посеред моєї роботи. Одне рев'ю це одне сповіщення з усією твоєю думкою.

**Alex Tutor:** Доки ти не надішлеш рев'ю, коментарі позначені `Pending` («очікує»), і бачиш їх лише ти.

> **Вправа:** Sofia починає рев'ю й залишає три коментарі з позначкою `Pending`. Daniel уже може їх прочитати.

## Suggested changes: запропонуй точні слова

> **`copy/cart.json` у #134**
>
> ```diff
>    "cartTitle": "Your cart",
> +  "checkoutDisabledHint": "Cart is empty. Add items to checkout.",
>    "promoCodeLabel": "Promo code"
> ```
> Один доданий рядок: підказка під сірою кнопкою.

**Sofia:** До того ж «checkout» це іменник, а «check out» дієслово. Тож тут не лише холодно, а й неправильно.

**Alex Tutor:** Тоді не описуй виправлення, а напиши його. На панелі коментаря є кнопка для **запропонованої зміни** (suggestion; станом на 2026 рік це маленька іконка з плюсом і мінусом). Вона вставляє блок `suggestion` із поточним рядком, готовим до редагування.

> **Коментар Sofia до цього рядка**
>
> ````markdown
> ```suggestion
>   "checkoutDisabledHint": "Your cart is empty. Add a treat to check out.",
> ```
> "Check out" is the verb here. A friendlier tone, too.
> ````
> У блоці `suggestion` рядок, яким Sofia пропонує замінити доданий. Нижче пояснення, чому.

**Daniel:** У мене це виглядає як маленький diff із кнопкою `Commit suggestion` («закомітити пропозицію»). Один клік, і твій рядок стає комітом у моїй гілці, а GitHub додає тебе до співавторів коміту.

**Alex Tutor:** Пропозиції залиш для дрібних точних правок: текст, число, посилання. Для чогось більшого опиши проблему, а рішення нехай обере автор.

> **Вправа:** Розстав кроки, якими Sofia пропонує нове формулювання, у правильному порядку.

**Alex Tutor:** Suggestion зручний, але не для всього. Що з цього варто оформити саме так?

> **Вправа:** Що з цього добре підходить для запропонованої зміни (suggestion)?

## Помаранчева кнопка

> **`styles/checkout.css` у #134**
>
> ```diff
>  .checkout-button {
> -  background: #2e9e5b;
> +  background: #f28c28;
>    border-radius: 8px;
> ```
> `#2e9e5b` це теперішній зелений; `#f28c28` помаранчевий.

**Sofia:** Із зеленого на помаранчевий. Issue #131 нічого не каже про колір, і опис теж.

**Daniel:** Знову винен. Я однаково був у цьому файлі, а помаранчевий помітніший. Визнай.

**Alex Tutor:** Може, й так. Але це головна кнопка всього магазину, змінена для кожного клієнта, всередині виправлення бага, яке ніхто не читатиме як редизайн. Якщо наступного тижня замовлень поменшає, ніхто не знатиме, де шукати.

**Sofia:** І вона заслуговує на нормальну перевірку: помаранчевий проти зеленого, A/B-тестом, з окремим issue.

**Alex Tutor:** Це й є перевірка **меж зміни** (scope): порівняй diff з issue й описом. Усе зайве отримує питання, а не мовчазне схвалення.

![Рецензентка розпаковує посилку й знаходить замовлену річ і ще несподівану помаранчеву, яку з цікавістю піднімає.](https://productovi.com/courses/git-for-product/inline/reviewing-as-a-pm-illustration-4.webp)

> **Вправа:** #134 виправляє issue #131: кнопка оформлення лишається сірою після змін у кошику. Його diff ще й змінює `styles/checkout.css`: кнопка оформлення із зеленої стає помаранчевою. Ні issue, ні опис про колір не згадують. Чому зміна кольору не має потрапити на сайт у складі #134?

## Тон: як писати коментарі до рев'ю

**Alex Tutor:** Тепер напиши коментар до цього рядка. Пам'ятай, хто його читатиме: колега, який витратив на це три дні й читатиме твоє рев'ю о шостій вечора.

**Alex Tutor:** Допомагає кілька звичок. Коментуй зміну, а не людину. Пиши, чому, а не лише що. Питай, коли маєш сумнів. Позначай дрібниці як необов'язкові. І кажи, що вдалося.

**Daniel:** «Навіщо ти це зробив?» і «Яка причина зміни кольору?» питають те саме. Тільки одне з них звучить як допит.

**Sofia:** Тоді так: «Зміна кольору не входить у #131, а вона стосується кожного клієнта. Може, винесемо її в окреме issue й перевіримо там?»

**Alex Tutor:** Саме так. Конкретно, з причиною і з пропозицією, що робити далі.

> **Вправа:** Які з цих коментарів у рев'ю автор буде радий отримати й зможе за ними діяти? Познач усе, що підходить.

## Comment, Approve чи Request changes

**Alex Tutor:** Твої коментарі чекають. Щоб їх надіслати, натисни кнопку рев'ю вгорі `Files changed`: станом на 2026 рік вона називається `Submit review` («надіслати рев'ю»; у старішому інтерфейсі `Review changes`). Вона відкриває поле для підсумку й три варіанти.

**Alex Tutor:** `Comment` («коментар»): відгук без вердикту. `Approve` («схвалити»): це можна зливати. `Request changes` («запит на зміни»): щось має змінитися до мерджу.

**Daniel:** Ще до схвалень пишуть «LGTM»: «looks good to me», «як на мене, усе добре». Нормально, якщо це правда. Найгірше рев'ю це LGTM на pull request, який ніхто не відкривав.

**Sofia:** А `Start a review` проти `Add single comment`? Де тут це?

**Alex Tutor:** Це попередній крок. Ці дві кнопки вирішують, чи коментар чекає на твій вердикт, чи йде окремо. А сам вердикт завжди один із цих трьох.

![Рев'ю від PM: превʼю, далі Files changed для текстів і меж зміни, потім чернетка коментарів і один вердикт: коментар, схвалення або запит на зміни.](https://productovi.com/courses/git-for-product/diagrams/m3-l2-pm-review-flow-uk.png)

> **Вправа:** Зістав кожну ситуацію з кнопкою чи варіантом, який варто обрати Sofia.

**Sofia:** Текст це дрібна правка, а от колір для мене справжній блокер. Тож `Request changes`?

**Alex Tutor:** Так, якщо в підсумку чітко сказано, що саме блокує і чому. Не проси змін через кому і не схвалюй із надією, що колір помітить хтось інший.

**Daniel:** `Request changes` це не грубість. Це точність. Краще знати, що блокує мердж, ніж угадувати з купи коментарів.

**Alex Tutor:** Перш ніж писати, спробуй той самий вибір на спокійнішому pull request.

> **Вправа:** Інший pull request: preview працює в усіх перевірених випадках, а єдине зауваження це необов'язкове дружніше формулювання підказки. Яке рев'ю ти надішлеш?

**Alex Tutor:** Напиши підсумок зараз. Daniel прочитає його першим, над твоїми коментарями до рядків.

> **Вправа:** Напиши підсумок до рев'ю Sofia з вердиктом `Request changes` для #134 (2–4 речення). Її коментарі до рядків: пропозиція для тексту підказки в `copy/cart.json` і зауваження, що зміна кольору в `styles/checkout.css` не входить у #131. Preview спрацював у кожному випадку, який вона пробувала.

## Правила для main

**Alex Tutor:** Ти натискаєш `Submit review`. Блок мерджу внизу `Conversation` тепер каже «Changes requested», і мердж заблоковано, хоча Oscar схвалив зміни.

```text
Рев'ю на #134 після того, як Sofia надсилає своє
- [Approved] Oscar: Approved these changes: схвалив зміни
- [Changes requested] Sofia: Requested changes: зміна кольору поза межами #131
```

**Sofia:** Стоп, моє рев'ю його блокує? Daniel казав, що одного схвалення досить.

**Daniel:** Одне схвалення обов'язкове, а запит на зміни від будь-кого з правом запису тримає мердж, доки ця людина не схвалить або рев'ю не відхилять (dismiss). Це наш **захист гілки** (branch protection) для `main`.

**Alex Tutor:** Захист гілки (або ruleset у новіших налаштуваннях) це перелік правил, які GitHub примусово застосовує до гілки. Для `main` у Котокорму: зміни лише через pull requests, щонайменше одне схвалення, `build` і `test` мають пройти, усі обговорення розв'язані, а гілка не відстає від `main`.

**Daniel:** Останнє правило з'явилося після моєї березневої пригоди з панеллю cookie. Завтра побачиш його в дії.

**Sofia:** А Daniel не може просто схвалити власний pull request?

**Daniel:** Ні. GitHub не дає авторам схвалювати власні pull requests, а до правила зараховуються лише рев'ю від людей із правом запису.

> **Вправа:** Правила Котокорму для `main` вимагають одного схвалення, а Oscar і Sofia мають право запису. Перевірки пройдено. Чи може Daniel змерджити #134 просто зараз?

## Виправити, розв'язати, схвалити

**Alex Tutor:** За годину. Daniel натиснув `Commit suggestion` на підказці, повернув зелений другим комітом і відповів на обидва твої коментарі.

```text
Граф комітів, від найстарішого: fix/checkout-button після рев'ю
1. коміт f02a6d4 у main "Update FAQ answers"
2. гілка fix/checkout-button починається від коміту f02a6d4
3. коміт 3a9d1c4 у fix/checkout-button "Reproduce bug in a test"
4. коміт 8be2f70 у main "Add cat treats bundle"
5. коміт b7e4a05 у fix/checkout-button "Re-enable button after cart edits"
6. коміт 6f2c8a1 у main "Raise free-delivery threshold to 1000 UAH (#133)"
7. коміт a7d93e4 у main "Rewrite delivery page copy (#132)"
8. коміт c2d7f90 у fix/checkout-button "Update checkout hint copy" (виділено)
9. коміт f7a2b61 у fix/checkout-button "Restore checkout button colour" (виділено)
```

*Два нові коміти в гілці: c2d7f90 застосовує пропозицію Sofia, f7a2b61 повертає зелену кнопку. main не змінилася.*

**Daniel:** Повідомлення для твоєї пропозиції я написав сам: «Update checkout hint copy». GitHub показує тебе серед співавторів цього коміту. Твій перший рядок коду, можна сказати.

**Sofia:** Його відповідь під кольором: «Слушно. Помаранчевий переніс у #135, перевірмо його як слід». І він натиснув стрілки біля мого імені, щоб знову попросити моє рев'ю.

**Alex Tutor:** Тепер заверши коло. Кожне обговорення має кнопку `Resolve conversation` («позначити обговорення розв'язаним»), а правила Котокорму блокують мердж, доки відкрите хоч одне. У нас обговорення закриває той, хто його почав, коли його все влаштовує.

**Sofia:** Мій рядок на місці, зелений повернувся. Розв'язую обидва обговорення, і цього разу: `Approve`.

## Твоє власне рев'ю

**Alex Tutor:** Ще один pull request для тебе, від початку до кінця. #154 «Add gift note to checkout» відповідає на issue #139: клієнти просили додавати записку до замовлень, які вони дарують. Oscar уже схвалив код; решта твоя.

**Sofia:** Спершу issue, потім опис, потім preview, потім diff.

**Alex Tutor:** Добрий порядок. Потім напиши рев'ю так, ніби надсилаєш його насправді: коментарі до рядків, пропозиція, де доречно, і вердикт із підсумком.

> **Вправа:** Напиши своє рев'ю pull request #154: коментарі до рядків (із пропозицією, де доречно), вердикт і підсумок.

**Alex Tutor:** Наступний урок: усі іконки й кольори, які ти бачиш цього тижня, і кілька нових, прочитані з першого погляду.

**Daniel:** А завтра зранку я зливаю #134. Ну, щойно блок мерджу перестане вимагати від мене ще одну річ.

- Попередній урок: [Що таке pull request: анатомія сторінки PR](https://productovi.com/uk/courses/git-for-product/pull-request-anatomy.md)
- Наступний урок: [Іконки, кольори й перевірки: що означає кожен стан GitHub](https://productovi.com/uk/courses/git-for-product/icons-and-colours.md)

---
Productovi Learning. Безкоштовно, читати можна без реєстрації.