Що таке pull request: сторінка PR простими словами

Alex Tutor

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

Ви

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

Daniel

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

Alex Tutor

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

Alex Tutor

Шапка 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

Ви

Назва, номер, зелений бейдж 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.

Daniel

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

Alex Tutor

Питання 1

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

Оберіть одну відповідьУ main, а отже, на живому сайтіУ feature/gift-wrap-copy, гілці, де їх написалиУ feature/gift-wrap; main не змінюєтьсяПоки нікуди: мердж спрацьовує лише після релізу

Ви

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

Alex Tutor

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

Daniel

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

Alex Tutor

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

Ви

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

Alex Tutor

Питання 2

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

Draft
Add autumn sale banner#136

ПравдаНеправда

Alex Tutor

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

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

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

Alex Tutor

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

f02a6d4Update FAQ answers
3a9d1c4Reproduce bug in a test
8be2f70Add cat treats bundle
b7e4a05Re-enable button after cart editsfix/checkout-button
6f2c8a1Raise free-delivery threshold to 1000 UAH (#133)
a7d93e4Rewrite delivery page copy (#132)main

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

Alex Tutor

`Files changed` у #134

components/CheckoutButton.tsx        +9  −3
components/CheckoutButton.test.tsx  +24  −0
copy/cart.json                       +1  −0
styles/checkout.css                  +1  −1

Чотири файли. Числа показують, скільки рядків додано й видалено в кожному.

Ви

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

Daniel

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

Alex Tutor

Питання 3

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

Торкніться відповіді, а потім рядка, до якого вона належить. Можна й перетягувати.

Чи пройшли автоматичні тести і що каже лог?
Який рядок додано в copy/cart.json?
Що Oscar написав у своєму рев'ю?
У якому порядку Daniel робив зміни, крок за кроком?

Відповіді, які ще треба розмістити

Alex Tutor

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

Alex Tutor

Опис #134

## 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: як було і як стало.

Ви

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

Alex Tutor

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

Daniel

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

Alex Tutor

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

Alex Tutor

Питання 4

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

Оберіть усі правильні відповідіПроблема, яку розв'язує зміна, з посиланням на її issueПерелік усіх файлів, які змінює pull requestКроки, за якими рев'юер може перевірити результат«Pls review asap»Скриншоти «до» і «після» для помітної зміниЩо зміна свідомо не охоплює

Ви

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

Alex Tutor

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

Працюють 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.

Ви

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

Daniel

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

Alex Tutor

Питання 5

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

Оберіть одну відповідьЩойно #134 відкриютьКоли перший рев'юер схвалить #134Коли Daniel натисне Ready for reviewКоли #134 змерджать у main

Alex Tutor

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

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

Ви

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

Daniel

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

Alex Tutor

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

Alex Tutor

Питання 6

Які твердження про бічну панель #134 правильні? Познач усе, що підходить.

Оберіть усі правильні відповідіDaniel виконавець, тож його власні зміни вважаються схваленимиOscar і Sofia в Reviewers, бо Daniel попросив їх переглянути зміниЯкщо зняти мітку checkout, мердж заблокуєтьсяМітка bug допомагає сортувати й фільтрувати; код вона не змінюєDevelopment показує #131, issue, яке закриє мердж #134

Alex Tutor

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

Alex Tutor

Перевірки на останньому коміті #134

build
Successful in 1m: успішно за хвилину
test
Successful in 3m: успішно за три хвилини
preview
Preview deployed: попередню версію викладено, посилання View deployment

Daniel

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

Ви

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

Alex Tutor

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

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

Alex Tutor

Питання 7

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

Перевірки на найновішому коміті

build
test
preview

Оберіть одну відповідьЖивий сайт зламаний, і клієнти не можуть оформити замовленняНа новому коміті впав автоматичний тест; це треба виправити до мерджуPreview не вдався, тож поклацати нічогоУсе гаразд: червоним просто позначено перевірку, що йшла останньою

Alex Tutor

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

Ви

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

Alex Tutor

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

Daniel

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

Alex Tutor

Питання 8Коротка відповідь · Завдання з перевіркою ШІ

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

Напишіть відповідь і отримайте оцінку та відгук від нашого ШІ-рецензента.

Увійдіть, щоб отримати відгук ШІ

Alex Tutor

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

Ви

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

Daniel

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

Alex Tutor

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

Alex Tutor

Питання 9Кейс · Завдання з перевіркою ШІ

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

Pull request #149 «product page fixes», main ← fix/product-page. Опис: «fixed some stuff, pls review».

Що показують вкладки:

Issue, на яке він відповідає: #143 «Product cards round prices up», яке відкрила підтримка; pull request його не згадує. Картки показують 250 грн, кошик списує 249,99 грн, і клієнти питають, яка ціна правильна.
components/ProductCard.tsx: картки тепер показують точну ціну, 249,99 грн замість 250 грн.
components/ProductCard.test.tsx: новий тест на форматування ціни.
copy/product.json: напис на товарах, яких немає в наявності, змінюється з «Sold out» на «Back soon».
Перевірки: build, test і preview пройшли; посилання на preview працює.

Напиши новий опис із розділами What, Why, How to test і Screenshots (опис можна писати англійською, як заведено в команді, або українською). Познач, що рев'юерам треба вирішити.

Напишіть відповідь і отримайте оцінку та відгук від нашого ШІ-рецензента.

Увійдіть, щоб отримати відгук ШІ

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

Ви

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

Alex Tutor

На цьому все. Ви відповіли на всі завдання — чудова робота.

Наступний урок: Рев'ю очима PM: коментарі, пропозиції, approve