Іконки, кольори й перевірки: що означає кожен стан GitHub

У списку Pull requests репозиторію кожен рядок починається з іконки: це статус pull request. Станом на 2026 рік їх чотири, і кожна має не лише колір, а й власну форму:

• Відкритий (open): іконка pull request, дві точки, з'єднані лініями зі стрілкою. Зелена. Чекає на рев'ю чи мердж.
• Чернетка (draft): та сама іконка з пунктирною лінією. Сіра. Робота триває; змерджити не можна.
• Змерджений (merged): дві лінії сходяться в одну. Фіолетова. Зміни вже в базовій гілці.
• Закритий (closed): іконка pull request із маленьким хрестиком. Червона. Закритий без мерджу; до коду нічого не потрапило.

Маленька позначка біля назви це інше: зведений результат перевірок.

За замовчуванням список показує лише Open. Змерджені й закриті pull requests лежать разом у Closed, поруч. Деякі рядки створюють боти: Dependabot, наприклад, відкриває pull request щоразу, коли бібліотека, яку використовує сайт, отримує нову версію. У терміналі gh pr list --state merged показує лише змерджені.

Вкладку Closed у списку pull requests легко прочитати неправильно. Вона містить усі pull requests, які вже не відкриті, а це два дуже різні фінали:

• Змерджений: іконка мерджу, дві лінії сходяться. Зміни вже в базовій гілці. У Котокорму мердж у main за кілька хвилин потрапляє на сайт.
• Закритий без мерджу: іконка pull request із хрестиком. Його хтось закрив, і нічого з нього не дійшло до коду. Експеримент, що не вдався, дублікат чи робота, яку замінив кращий pull request.

Тож «він у Closed» каже лише, що pull request завершено, але не як. Читай іконку в кожному рядку, а не назву вкладки.

Для PM це важливо в кожному звіті. «За тиждень закрито п'ять pull requests» може означати п'ять випущених змін або п'ять покинутих. Рахуй змерджені й закриті окремо й називай кожен: «#132 і #133 змерджено, #127 закрили без мерджу». Якщо потрібен лише один вид, відфільтруй: is:merged або is:unmerged у полі пошуку над списком.

Сам колір слабкий сигнал. На сонці з телефона фіолетовий і сірий виглядають майже однаково. Приблизно кожен 12-й чоловік і кожна 200-та жінка бачать деякі кольори інакше, найчастіше червоний і зелений. А в налаштуваннях вигляду GitHub є теми для людей із порушеннями сприйняття кольору, які замінюють червоний і зелений іншими кольорами, тож екран колеги може зовсім не збігатися з твоїм.

Тому GitHub супроводжує кожен колір стану формою і словом: галочка, хрестик, пунктир, дві лінії, що сходяться; «Merged», «Draft», «Closed». Читай їх першими.

Та сама звичка діє, коли ти пишеш чи говориш про стани. Називай їх:

• «#133 змерджено».
• «#136 досі чернетка».
• «#138 закрили як незаплановане».

Ніколи «фіолетовий» чи «той сірий». Слово-колір змушує читача бачити те саме, що й ти, а дехто не може. Слово-стан працює для всіх, на будь-якому екрані й у будь-якій темі, і зрозуміле, навіть коли його вимовляють уголос на зустрічі.

Issues мають власні іконки, і всі вони кола, тож їх одразу видно серед pull requests. Станом на 2026 рік:

• Відкрите: коло з крапкою всередині, зелене.
• Закрите як виконане (completed): коло з галочкою, фіолетове. Роботу зроблено. Фіолетовий тут означає «завершено», як і на змердженому pull request.
• Закрите як незаплановане (not planned): коло з косою рискою, сіре. Команда вирішила цього не робити.

Коли issue закривають, GitHub питає причину, і іконка її відображає. Команда, яка вирішила не показувати ціни в євро, закриває цю ідею як незаплановану, а не вдає, що її зроблено. У терміналі: gh issue close 138 --reason "not planned". GitHub пропонує ще й причину «duplicate» (дублікат).

Для PM це різниця між випущеним і скасованим. Обидва issues закриті, але лише одне означає, що роботу хтось зробив. У звітах про issues ніколи не рахуй їх разом. І пам'ятай: фіолетовий змерджений pull request і фіолетове виконане issue мають спільний колір, але не форму.

Перевірки GitHub (checks) це автоматичні запуски, які GitHub показує на кожному коміті pull request: збирання сайту, тести, деплой preview. Команда може зробити деякі з них обов'язковими (required status checks), і тоді pull request не змерджиш, поки одна з них падає.

Кожна перевірка має один із чотирьох результатів (станом на 2026 рік):

• коло з галочкою, зелене: пройшла;
• коло з хрестиком, червоне: впала;
• крапка, жовта: у черзі чи ще триває;
• сіра, часто коло з косою рискою: пропущена (skipped) або нейтральна; перевірка не запускалася чи не дала вердикту.

Маленька позначка біля назви pull request у списку підсумовує всі його перевірки: один червоний хрестик означає, що впала принаймні одна. Відкрий pull request або виконай gh pr checks 137, щоб побачити, яка саме.

Читай результат як він є: це твердження про конкретну гілку. Червоний хрестик на #137 від Dependabot означає, що оновлення бібліотеки зламало тест у його власній гілці. Живий сайт, зібраний із main, працює.

Сіра, пропущена перевірка це найпідступніший результат на сторінці. Вона виглядає спокійно, вона не червона, і станом на 2026 рік пропущене завдання не блокує мердж, навіть коли перевірка обов'язкова. GitHub вважає, що «скаржитися нема на що».

Але «пропущено» означає, що перевірка не запускалася. Preview ніхто не зібрав, тести ніхто не прогнав. Це як пропускний пункт із порожньою будкою й піднятим шлагбаумом: машини проїжджають, і ніхто не зазирнув усередину.

Перевірки пропускаються з буденних причин: процес запускається лише тоді, коли змінюються певні файли, pull request від бота не отримує секретів, або завдання залежить від іншого, яке впало. На #137 від Dependabot preview пропущено, тож посилання на preview немає.

Що це означає для PM:

• Не звітуй про пропущену перевірку як про «все зелене».
• Якщо пропущена перевірка стосується того, що тобі треба переглянути (скажімо, preview), спитай, чому вона не запускалася, перш ніж схвалювати.
• У статусі кажи прямо: «test упав, preview пропущено».

Рев'ю теж мають іконки. На сторінці pull request вони стоять біля імені кожного рев'юера в бічній панелі (станом на 2026 рік):

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

У списку pull requests кожен рядок підсумовує рев'ю словами: «Review required» (схвалення ще немає), «Approved» чи «Changes requested». Pull request від Dependabot, який ніхто не відкривав, каже «Review required».

Дві речі варто пам'ятати. Коментар не схвалення: рев'юер, який лише ставив питання, ще не сказав «так». А крапка біля твого власного імені означає, що хтось чекає саме на тебе. Швидкий фільтр для цього: review-requested:@me у пошуку pull requests або gh pr list --search "review-requested:@me" у терміналі.

Мітки (labels) це єдине місце, де колір нічого не означає для GitHub. Колір мітки обирає той, хто її створює. Нові репозиторії мають кілька стандартних, як-от червону bug, але команда хоч завтра може зробити bug рожевою, а синя мітка синя лише тому, що хтось обрав синій.

Тож розрізняй дві речі:

• стан показує іконка зліва в рядку: відкритий, чернетка, змерджений, закритий;
• мітка каже, чого стосується елемент: bug, checkout, content, idea, dependencies.

Червона мітка bug на відкритому pull request це просто відкритий pull request про баг. Вона не означає «терміново», «впало» чи «заблоковано». Синя мітка dependencies не означає, що перевірки пройшли чи що pull request чекає на рев'ю. Деякі мітки додаються автоматично: Dependabot ставить dependencies на власні pull requests.

Невеликий набір міток читати легше, ніж великий. П'ять міток, зрозумілих усій команді, кращі за п'ятдесят у дванадцяти кольорах. Фільтр за міткою: gh pr list --label bug.

Унизу Conversation блок мерджу показує, що ще стоїть між pull request і мерджем. Станом на 2026 рік він може казати:

• Review required: схвалення ще немає. Заблоковано.
• Changes requested: рев'юер попросив змін. Заблоковано.
• Some checks were not successful: перевірка впала. Заблоковано, якщо вона обов'язкова.
• Some checks haven't completed yet: перевірки тривають. Чекай.
• This branch is out-of-date with the base branch: коли правила вимагають оновленої гілки, натисни Update branch.
• This branch has conflicts that must be resolved: спершу хтось має розв'язати конфлікти.
• All checks have passed і no conflicts, плюс схвалення: кнопка мерджу стає зеленою.

Update branch зливає базову гілку в гілку pull request (у терміналі gh pr update-branch 134). Це новий коміт, тож перевірки запускаються знову, і тепер вони тестують зміну разом з усім, що потрапило в main відтоді. Точні формулювання з роками змінюються; зміст ні.

Розрізняй два фінали pull request. Змерджений переніс свої коміти в базову гілку. Закритий закрили без мерджу, і до коду нічого з нього не потрапило. Обидва лежать у Closed у списку, тож читай іконку, а не вкладку.

У Котокорму мердж #134 у main запускає ланцюжок:

• Із Squash and merge у main з'являється один коміт: «Fix checkout button after cart edits (#134)».
• Ключове слово Fixes #131 закриває issue #131 як виконане: коло з галочкою.
• Змерджена гілка видаляється автоматично, це налаштування репозиторію, яке команда ввімкнула.
• Починається деплой. «Змерджено» стає «на сайті» лише тоді, коли він завершиться, за кілька хвилин; тоді варто ще раз глянути на живий сайт із телефона.

І три питання про будь-який мердж: змерджено куди, коли і чи воно досі там? Для #134: main, 9:40, і так, ніхто його не відкотив.