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

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

Найважливіший факт стоїть у рядку під назвою: «Daniel wants to merge 2 commits into main from fix/checkout-button». Гілка після into це база (base): сюди потраплять коміти. Гілка після from це гілка змін (compare): звідти коміти приходять. GitHub малює це ще й так: main ← fix/checkout-button.

База не завжди main. Pull request може йти в іншу гілку фічі або в develop, якщо команда спершу збирає роботу там. Його мердж змінює лише цю базову гілку; main і живий сайт лишаються як були, доки наступний мердж не понесе роботу далі. Коли pull request відкривають із термінала, ту саму базу задає gh pr create --base main.

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

Навіщо відкривати pull request, поки робота не завершена? Команда бачить, що наближається, автоматичні перевірки вже запускаються на кожному новому коміті, і ніхто не витрачає рев'ю на пів виправлення. Daniel відкриває чернетки рано навмисно.

Коли автор натискає Ready for review, бейдж стає зеленим (Open), а рев'юери отримують сповіщення. Це працює й у зворотний бік: Convert to draft у бічній панелі повертає відкритий pull request у чернетку, наприклад коли автор знаходить проблему посеред рев'ю. У терміналі це gh pr create --draft, gh pr ready 136 і gh pr ready 136 --undo.

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

Під шапкою pull request є чотири вкладки (станом на 2026 рік), кожна з лічильником. Обирай вкладку за питанням, яке ставиш.

• Conversation: стрічка подій. Спершу опис, далі коментарі, рев'ю, нові коміти й зміни стану в порядку часу. Унизу стоїть блок мерджу.
• Commits: власні коміти гілки, крок за кроком. Лише коміти з гілки змін, а не ті, що тим часом з'явилися в main. У терміналі той самий набір показує git log --oneline main..fix/checkout-button.
• Checks: автоматичні запуски, як-от build, test і preview, з логами.
• Files changed: diff усього pull request. Кожен змінений файл, видалені рядки червоні, додані зелені, з підрахунком для кожного файлу. Той самий підсумок друкує git diff --stat main...fix/checkout-button.

Перелік файлів це ще й перша перевірка меж зміни. У #134 виправлення кнопки зачепило ще й styles/checkout.css: про такий файл варто спитати.

Опис це перший коментар на Conversation, і для рев'юера це найкорисніший текст на сторінці. Добрий опис читається як маленький бриф із чотирьох частин:

• What: зміна простими словами.
• Why: проблема з посиланням на її issue (Fixes #131).
• How to test: кроки, які може повторити будь-хто, починаючи з посилання на preview.
• Screenshots: як було і як стало, для всього, що бачать клієнти.

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

Чого там не треба: переліку всіх змінених файлів (він уже є у Files changed) і прохань на кшталт «pls review asap», які нічого не кажуть про саму зміну. Слабкий опис коштує автору зустрічі: троє рев'юерів ставлять ті самі три питання, або pull request ніхто не відкриває взагалі.

Для PM опис ще й мірило меж: усе в diff, про що опис мовчить, варте питання.

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

Щоб опис не починався з порожнього поля, команди тримають шаблон pull request: Markdown-файл у репозиторії, зазвичай .github/pull_request_template.md. Коли хтось відкриває новий pull request, GitHub копіює шаблон в опис, і кожен PR починається з тих самих заголовків: What, Why, How to test, Screenshots.

Рядки всередині <!-- --> це підказки для автора; у готовому описі GitHub їх не показує. Заповнити шаблон можна за дві хвилини, а порожні заголовки нагадують, про що спитають рев'юери. У GitLab та сама ідея називається шаблонами merge request.

Fixes #131 в описі це більше, ніж посилання. Fixes це ключове слово закриття (closing keyword): коли pull request змерджать в основну гілку репозиторію (у Котокорму це main), GitHub сам закриє issue #131.

Працюють три дієслова в будь-якій формі: close, fix і resolve. Тож Closes #131, Fixed #131 і Resolves #131 теж спрацюють. Кожне issue потребує власного ключового слова: Fixes #131, fixes #132. Без ключового слова «#131» це лише згадка: сторінки посилаються одна на одну, і нічого не закривається.

Бічна панель підтверджує зв'язок у розділі Development: «Successfully merging this pull request may close these issues» і далі #131 (так GitHub формулює станом на 2026 рік).

Важливий момент. Відкриття pull request, схвалення чи вихід із чернетки лише пов'язують дві сторінки; issue лишається відкритим до мерджу. І ключове слово діє лише на мердж в основну гілку. Котокорм викладає кожен мердж у main за кілька хвилин, тож підтримка бачить закриття #131 приблизно тоді, коли виправлення з'являється на сайті.

Ключові слова закриття мають одну умову, яку легко проґавити: вони діють лише тоді, коли pull request змерджено в основну гілку. Це гілка, з якої відкривається репозиторій, зазвичай main.

Деякі pull requests ідуть деінде. Зміна текстів може бути спрямована в feature/gift-wrap, гілку, де будують більшу фічу, а команди з гілкою develop зливають туди більшість pull requests. Змерджиш такий pull request, і його Closes #140 нічого не зробить: issue лишиться відкритим, бо робота ще не дійшла до основної гілки.

І це правильна поведінка. Issue має закриватися, коли виправлення справді в main, а не коли воно на крок ближче.

Тож якщо база не основна гілка, вирішіть, як закриється issue. Додайте ключове слово в pull request, який зрештою понесе роботу в main, або закрийте issue вручну, коли той мердж станеться. Перш ніж звітувати, що щось готове, прочитай базу в шапці, а тоді подивися на стан issue.

Бічна панель праворуч відповідає на питання «хто і для чого»:

• Reviewers: люди, яких попросили про вердикт. На #134 це Oscar для коду і Sofia для продуктового боку.
• Assignees: хто відповідає за те, щоб pull request дійшов до кінця, зазвичай автор. Призначення нічого не схвалює.
• Labels: кольорові мітки для сортування й фільтрів, як-от bug і checkout. Вони не змінюють код і нічого не блокують.
• Projects і Milestone: місце роботи в планах команди.
• Development: пов'язане issue, яке закриє ключове слово.

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

У терміналі ті самі поля задає gh pr edit 134 --add-reviewer oscar --add-label bug.

Щоразу, коли автор надсилає коміт, на ньому автоматично запускаються перевірки (checks). У Котокорму їх три: build (чи сайт досі збирається?), test (чи проходять автоматичні тести?) і preview. Перші дві це безперервна інтеграція (CI): роботи, які перевіряють кожну зміну. preview викладає гілку на тимчасову копію сайту з власним посиланням, тож PM може поклацати зміну на телефоні раніше, ніж її побачить будь-який клієнт.

Перевірки запускаються на гілці, на її найновішому коміті, а не на живому сайті. Сайт і далі показує main. Тому червоний test означає «ця зміна зламала тест, її треба переглянути», а не «клієнти не можуть оформити замовлення». Падіння на старішому коміті перестає мати значення, щойно новіший проходить. У терміналі той самий список друкує gh pr checks 134.

Унизу Conversation блок мерджу підсумовує, чи можна зливати pull request: рев'ю, перевірки й конфлікти. «Review required» разом із «Merging is blocked» (так GitHub пише станом на 2026 рік) означає, що перевірки можуть бути зелені, але схвалення ще немає.