# Що таке pull request: анатомія сторінки PR

> Що таке pull request, згори донизу: базова гілка й гілка змін, чернетка і готовий PR, чотири вкладки, опис і шаблон pull request, рев'юери й мітки, пов'язані issues, перевірки й блок мерджу.

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

## Що таке pull request: готово до рев'ю

**Alex Tutor:** Пам'ятаєш #134, виправлення кнопки від Daniel? Сьогодні зранку він натиснув `Ready for review` («готово до рев'ю») і попросив двох людей переглянути зміни. Один з них Oscar, наш бекенд-розробник. А друга людина це ти, від продуктової команди Котокорму.

**Sofia:** Я? Рев'ю зміни в коді? Diff я вже читаю, але оцінити код не зможу.

**Daniel:** І не треба. Код переглядає Oscar. А ти перевіряєш, що виправлення робить те, про що просила підтримка, і що клієнти бачать те, що треба. Але спершу прочитай сторінку згори донизу.

**Alex Tutor:** **Pull request** (PR) це пропозиція: «візьміть коміти з моєї гілки й змерджте їх у ту». Його сторінка збирає все, що потрібно для рішення: опис, обговорення, коміти, автоматичні перевірки й diff.

**Alex Tutor:** Та сама річ, інша назва: у GitLab це **merge request**, скорочено MR. Pull request і merge request відрізняються лише назвою. GitHub називає запит за тим, що зміни «підтягують», а GitLab за самим злиттям.

![Сторінка pull request: шапка з напрямком мерджу, чотири вкладки, опис, блок мерджу внизу і бічна панель із рев'юерами, мітками та пов'язаним issue.](https://productovi.com/courses/git-for-product/diagrams/m3-l1-pr-page-map-uk.png)

```text
Шапка pull request #134
- [Open] Fix checkout button after cart edits #134: Daniel wants to merge 2 commits into main from fix/checkout-button: Daniel пропонує влити 2 коміти з fix/checkout-button у main
```

**Sofia:** Назва, номер, зелений бейдж `Open` і рядок під ними: «Daniel wants to merge 2 commits into `main` from `fix/checkout-button`».

**Alex Tutor:** У цьому рядку найважливіший факт сторінки: напрямок. `main` це **базова гілка** (base), куди підуть зміни. `fix/checkout-button` це **гілка змін** (compare), звідки вони прийдуть. GitHub показує це ще й так: `main` ← `fix/checkout-button`.

![Невеликий човен чекає у шлюзі між вузьким бічним каналом і широким головним, а доглядач шлюзу з планшетом його перевіряє.](https://productovi.com/courses/git-for-product/inline/pull-request-anatomy-illustration-2.webp)

*Спершу читай напрямок: із якої гілки йде робота і куди.*

**Daniel:** База не завжди `main`. Деякі pull requests ідуть в іншу гілку фічі, а деякі команди спершу зливають усе в `develop`. Перш ніж радіти, завжди читай стрілку.

> **Вправа:** Шапка іншого pull request каже: «wants to merge 3 commits into `feature/gift-wrap` from `feature/gift-wrap-copy`». Його змерджили. Куди потрапили три коміти?

## Чернетка PR чи готовий до рев'ю

**Sofia:** Учора бейдж був сірий і казав `Draft`. Що змінилося, крім кольору?

**Alex Tutor:** **Чернетка pull request** (draft) означає «робота триває, рев'ю поки не треба». Чернетку GitHub не змерджить: там, де мала б бути кнопка мерджу, стоїть кнопка `Ready for review`.

**Daniel:** Я навмисно відкриваю чернетки рано. Команда бачить, над чим я працюю, автоматичні перевірки вже запускаються на кожному коміті, і ніхто не витрачає рев'ю на пів виправлення.

**Alex Tutor:** Це працює й у зворотний бік. Станом на 2026 рік невелике посилання `Convert to draft` у бічній панелі повертає відкритий pull request у чернетку, наприклад коли автор знаходить проблему посеред рев'ю.

**Sofia:** Тобто і чернетка, і відкритий PR ще не змерджені. Бейдж каже, чи автор уже чекає на рев'ю.

> **Вправа:** Pull request #136 має такий бейдж. Якщо рев'юер зараз його схвалить, автор зможе одразу його змерджити.

## Чотири вкладки pull request

**Alex Tutor:** Під шапкою чотири вкладки (станом на 2026 рік): `Conversation`, `Commits`, `Checks` і `Files changed`. На кожній є лічильник.

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

**Alex Tutor:** `Commits` («коміти») показує коміти гілки, тут їх два: `3a9d1c4` «Reproduce bug in a test» і `b7e4a05` «Re-enable button after cart edits». `Checks` («перевірки») показує автоматичні запуски з їхніми логами.

```text
Граф комітів, від найстарішого: Що охоплює вкладка Commits у #134
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)"
```

*Pull request містить лише два коміти з fix/checkout-button. Тим часом main пішла вперед на три коміти; що це означає для мерджу, покаже урок 3.*

**Alex Tutor:** `Files changed` («змінені файли») це diff усього pull request: кожен файл, якого він торкається, видалені рядки червоні, додані зелені, як у модулі 1.

> **`Files changed` у #134**
>
> ```text
> components/CheckoutButton.tsx        +9  −3
> components/CheckoutButton.test.tsx  +24  −0
> copy/cart.json                       +1  −0
> styles/checkout.css                  +1  −1
> ```
> Чотири файли. Числа показують, скільки рядків додано й видалено в кожному.

**Sofia:** Кнопка, тест, тексти кошика... і `styles/checkout.css`? Навіщо виправленню бага змінювати стилі?

**Daniel:** Уважно. Прибережи це питання для завтрашнього рев'ю.

> **Вправа:** Треба відповісти на чотири питання про #134. Зістав кожне питання з вкладкою, де знайдеться відповідь.

## Як написати опис pull request

**Alex Tutor:** Повернімося до `Conversation`. Перший коментар це опис, який Daniel написав, коли відкривав pull request. Для рев'юера це найкорисніший текст на сторінці.

> **Опис #134**
>
> ```markdown
> ## What
> The checkout button stays active after a customer changes
> quantities or removes items. When the cart is empty, the button
> is disabled and a short hint explains why.
>
> ## Why
> Fixes #131. After editing the cart, customers saw a grey button
> and couldn't check out until they reloaded the page.
>
> ## How to test
> 1. Open the preview link and add two products to the cart.
> 2. Change the quantity of one of them: the button stays green.
> 3. Remove every item: the button turns grey and shows a hint.
>
> ## Screenshots
> Before / after, cart page on a phone (two images).
> ```
> Опис, як і коміти, команда пише англійською. What: що змінилося. Why: навіщо, з посиланням на issue. How to test: як перевірити. Screenshots: як було і як стало.

**Sofia:** Що, навіщо, як перевірити, скриншоти. Схоже на маленький бриф.

**Alex Tutor:** Саме так. What: зміна простими словами. Why: проблема з посиланням на її issue. How to test: кроки, які може повторити будь-хто. Screenshots: як було і як стало, для всього, що бачать клієнти. Деякі команди додають п'яту частину: що свідомо не входить у зміну.

![На планшеті короткий бриф із чотирьох порожніх розділів, кожен позначено маленьким значком: олівець, мішень, галочка в списку й рамка для фото.](https://productovi.com/courses/git-for-product/inline/pull-request-anatomy-illustration-3.webp)

*Що, навіщо, як перевірити і як це виглядає.*

**Daniel:** Добрий опис економить мені зустріч. Слабкий каже «fixed checkout, pls review», і тоді троє рев'юерів ставлять мені ті самі три питання.

**Alex Tutor:** З назвою так само. «Fix checkout button after cart edits» каже, що змінюється і де. «Checkout fixes» або «Daniel's branch» у списку з п'ятдесяти pull requests не кажуть нічого.

> **Вправа:** Що з цього варто мати в доброму описі pull request? Познач усе, що підходить.

**Alex Tutor:** Коротка перевірка перед шаблоном. Два pull requests поруч.

> **Вправа:** У твоїй черзі на рев'ю два pull requests. Який із них можна переглянути, не поставивши автору жодного питання?

## Шаблон pull request

**Alex Tutor:** **Шаблон pull request** це Markdown-файл, який команда тримає в репозиторії, зазвичай `.github/pull_request_template.md`. Коли хтось відкриває новий pull request, GitHub підставляє його в опис, тож кожен PR починається з тих самих чотирьох заголовків, а не з порожнього поля.

> **`.github/pull_request_template.md` у Котокорму**
>
> ```markdown
> ## What
> <!-- The change in plain words -->
>
> ## Why
> <!-- The problem. Link the issue: Fixes #... -->
>
> ## How to test
> 1. <!-- Steps anyone can repeat, starting from the preview link -->
>
> ## Screenshots
> <!-- Before / after, for anything customers see -->
> ```
> Шаблон, як і опис, команда пише англійською. Рядки `<!-- -->` це підказки для автора: у готовому описі GitHub їх не показує.

**Daniel:** Наш з'явився після надто багатьох описів «pls review». Заповнити його можна за дві хвилини, а порожні заголовки нагадують, про що спитають рев'юери. У GitLab та сама ідея: шаблони merge request.

## Fixes #131

**Sofia:** У частині «Why» написано «Fixes #131». Це просто посилання?

**Alex Tutor:** Більше, ніж посилання. #131 це issue, яке відкрила підтримка: «Checkout button stays grey after editing cart». `Fixes` це **ключове слово закриття** (closing keyword): коли #134 змерджать в основну гілку, GitHub сам закриє #131.

**Alex Tutor:** Працюють close, fix і resolve у будь-якій формі: `Closes #131`, `Fixed #131`, `Resolves #131`. Без ключового слова «#131» це лише згадка. Обидві сторінки посилаються одна на одну, і нічого не закривається.

**Daniel:** Бічна панель підтверджує це в розділі `Development`. Станом на 2026 рік там написано «Successfully merging this pull request may close these issues» («мердж цього pull request може закрити такі issues») і стоїть #131.

**Sofia:** А оскільки ми викладаємо сайт після кожного мерджу, підтримка побачить закриття issue приблизно тоді, коли виправлення з'явиться на сайті.

**Daniel:** Так, з різницею в кілька хвилин. Один нюанс: ключове слово працює лише в pull requests до основної гілки. Змерджиш такий в іншу гілку, і нічого не закриється.

> **Вправа:** Pull request #134 містить `Fixes #131` і спрямований у `main`, основну гілку. Коли GitHub закриє issue #131?

**Alex Tutor:** Нюанс, про який сказав Daniel, вартий окремої перевірки. Правда чи ні?

> **Вправа:** Pull request від Emma, контент-маркетологині Котокорму, іде в `feature/gift-wrap`, а не в `main`. В описі написано `Closes #140`. Коли його змерджать, GitHub закриє issue #140.

## Хто що робить: бічна панель

**Alex Tutor:** Праворуч бічна панель. `Reviewers` («рев'юери»): кого попросили переглянути зміни, тут Oscar і ти. `Assignees` («виконавці»): хто відповідає за те, щоб pull request дійшов до кінця, зазвичай автор, тобто Daniel.

**Alex Tutor:** `Labels` («мітки»): кольорові позначки для сортування й фільтрів, тут `bug` і `checkout`. `Projects` і `Milestone` показують місце роботи в планах команди, про це модуль 5. А в `Development` пов'язане issue.

**Sofia:** Навіщо двоє рев'юерів? Хіба одного не досить?

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

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

> **Вправа:** Бічна панель #134 показує: `Reviewers` Oscar і Sofia, `Assignees` Daniel, `Labels` `bug` і `checkout`, а в `Development` issue #131. Правила Котокорму для `main` вимагають одного схвалення. Які твердження правильні? Познач усе, що підходить.

## Перевірки й блок мерджу

**Alex Tutor:** Щоразу, коли Daniel надсилає коміт, автоматично запускаються **перевірки** (checks). У Котокорму їх три: `build` (чи сайт досі збирається?), `test` (чи проходять автоматичні тести?) і `preview`.

```text
Перевірки на останньому коміті #134
- [All checks have passed] build: Successful in 1m: успішно за хвилину
- [All checks have passed] test: Successful in 3m: успішно за три хвилини
- [All checks have passed] preview: Preview deployed: попередню версію викладено, посилання View deployment
```

**Daniel:** `build` і `test` це **безперервна інтеграція** (continuous integration, CI): роботи, які перевіряють кожну зміну. А `preview` саме для тебе. Він викладає цю гілку на тимчасову копію сайту з власним посиланням.

![Троє маленьких привітних роботів стоять біля конвеєра й перевіряють посилку, кожен піднімає зелений вогник.](https://productovi.com/courses/git-for-product/inline/pull-request-anatomy-illustration-4.webp)

**Sofia:** Тобто можна поклацати виправлення на телефоні ще до того, як його побачить хоч один клієнт. Це й є посилання з «How to test».

**Alex Tutor:** Саме так. Тепер прогорни `Conversation` донизу. **Блок мерджу** (merge box) підсумовує, чи можна зливати pull request: рев'ю, перевірки й конфлікти.

**Alex Tutor:** Зараз він каже «Review required» і «Merging is blocked» (так GitHub формулює станом на 2026 рік): потрібне рев'ю, мердж заблоковано. Перевірки зелені, але схвалення ще немає. На уроці 3 розберемо всі повідомлення, які він може показати.

> **Вправа:** Daniel надсилає ще один коміт у `fix/checkout-button`, і перевірки тепер виглядають так. Що це означає?

## Поясни підтримці

**Alex Tutor:** Підтримка помітила посилання на #134 у своєму issue і питає тебе: «Там написано "Fixes #131". Це означає, що кнопку вже полагодили?»

**Sofia:** Ще ні. Pull request відкритий, а не змерджений.

**Alex Tutor:** Відповідай їм двома-трьома реченнями: що означає цей рядок, що має статися спершу і як вони дізнаються, що все готово.

**Daniel:** І без дат, будь ласка. Воно ще має пройти рев'ю.

> **Вправа:** Підтримка питає: «У pull request #134 написано "Fixes #131". Це означає, що кнопку оформлення вже полагодили?» #134 відкритий і чекає на рев'ю, а Котокорм викладає кожен мердж у `main` за кілька хвилин. Напиши відповідь на 2–3 речення без Git-жаргону.

## Перепиши слабкий опис

**Alex Tutor:** У твоїй черзі ще один pull request. Хтось із колег відкрив #149 «product page fixes». Увесь опис: «fixed some stuff, pls review».

**Sofia:** Я навіть не розумію, що тут треба перевіряти.

**Daniel:** Я сам колись написав саме такий опис. У п'ятницю ввечері. До вівторка ніхто цей pull request не відкрив.

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

> **Вправа:** Перепиши опис pull request #149 так, щоб рев'юер знав, що змінилося, навіщо, як це перевірити і що треба вирішити.

**Alex Tutor:** Завтра ти робиш справжнє рев'ю #134: preview, тексти й той файл стилів.

**Sofia:** Чотири вкладки, одне питання: чи робить воно те, про що просили в #131, і нічого зайвого?

- Попередній урок: [Конфлікти злиття (merge conflict): чому виникають і що робити](https://productovi.com/uk/courses/git-for-product/merge-conflicts.md)
- Наступний урок: [Рев'ю pull request очима PM: коментарі, пропозиції, approve](https://productovi.com/uk/courses/git-for-product/reviewing-as-a-pm.md)

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