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

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

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

## Статуси pull request у ранковому списку

**Alex Tutor:** Доброго ранку. Ще один день у продуктовій команді Котокорму: Daniel ось-ось змерджить #134. Поки він цього не зробив, відкрий у репозиторії вкладку `Pull requests` і просто хвилину подивися на список.

```text
Pull requests у catchow/website: Open
- [Open] Fix checkout button after cart edits #134: автор Daniel · Approved · перевірки пройдено · bug, checkout
- [Draft] Add autumn sale banner #136: авторка Emma · Draft · content
- [Open] Bump image-optimizer from 2.3.0 to 2.4.1 #137: автор dependabot · Review required · 1 перевірка впала · dependencies
```

**Sofia:** Три рядки, і кожен починається з іконки: дві зелені, одна сіра. А біля кожної назви ще маленька позначка.

**Alex Tutor:** Іконка ліворуч це статус pull request. Станом на 2026 рік: зелений для відкритого, сірий для чернетки, фіолетовий для змердженого, червоний для закритого. Маленька позначка біля назви це результат перевірок.

**Sofia:** А де змерджені? #133 і #132 від Emma тут немає.

**Alex Tutor:** Список за замовчуванням показує `Open`. І змерджені, і закриті pull requests лежать у `Closed`, поруч.

**Daniel:** А #137 від Dependabot, бота GitHub, який відкриває pull request, коли бібліотека, якою ми користуємося, виходить у новій версії. Такими займається Oscar.

> **Вправа:** Це чотири іконки станів pull request без підписів. Зістав кожну пронумеровану іконку з її станом.

## Спершу форма, потім колір

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

**Alex Tutor:** Тоді читай форму. Open: іконка pull request, дві точки, з'єднані лініями, зі стрілкою. Draft: та сама іконка з пунктиром. Merged: дві лінії, що сходяться в одну. Closed: іконка pull request із маленьким хрестиком.

![На яскравому сонці людина мружиться на телефон, де значки статусів відрізняються формою: просте коло, коло з галочкою й перекреслене коло.](https://productovi.com/courses/git-for-product/inline/icons-and-colours-illustration-2.webp)

**Alex Tutor:** Приблизно кожен 12-й чоловік і кожна 200-та жінка бачать деякі кольори інакше, найчастіше червоний і зелений. Тому GitHub додає до кожного кольору стану форму й слово.

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

**Alex Tutor:** Тому, коли пишеш про стани, називай їх. «#133 змерджено», «#138 закрито як незаплановане». І ніколи «та фіолетова».

> **Вправа:** Це вкладка `Closed` списку pull requests. Жоден pull request у ній не доніс свої зміни до `main`.

**Alex Tutor:** Тепер перенесімо це в справжнє повідомлення в чаті.

> **Вправа:** Колега з продажів питає в чаті, як справи зі змінами доставки. Яка відповідь зрозуміла всім, хай який у них екран чи зір?

## В issues свої стани

**Alex Tutor:** Тепер вкладка `Issues`. Іконки issues круглі. Відкрите issue це коло з крапкою посередині, зелене.

```text
Issues у catchow/website
- [Open] Checkout button stays grey after editing cart #131: відкрила підтримка · bug, checkout · пов'язаний pull request #134
- [Open] Test an orange checkout button #135: відкрив Daniel · idea
- [Closed as completed] Courier rates up from 1 June #120: Closed as completed: закрито як виконане
- [Closed as not planned] Show prices in euros #138: Closed as not planned: закрито як незаплановане
```

**Sofia:** #120 це issue від фінвідділу з модуля 1. Фіолетове, з галочкою всередині кола.

**Alex Tutor:** Закрите як виконане: роботу зроблено. Фіолетовий тут означає те саме, що й на змердженому pull request: завершено. #138 закрили як незаплановане: сіре коло з косою рискою.

**Daniel:** Це була ідея показувати ціни в євро. Ми вирішили від неї відмовитися, тож закрили як незаплановане, а не вдавали, що зробили. Коли закриваєш issue, GitHub питає про причину.

**Sofia:** Тобто обидва закриті, але лише одне означає, що роботу хтось виконав.

**Alex Tutor:** Для продакта це різниця між «випустили» й «відмовилися». Коли звітуєш про issues, ніколи не рахуй їх разом.

![Дві закриті коробки: одну зі стрічкою й печаткою-галочкою виносять покупцям, другу з печаткою-хрестиком відкладають на задню полицю.](https://productovi.com/courses/git-for-product/inline/icons-and-colours-illustration-3.webp)

*Обидві закриті, але лише одна означає, що роботу зроблено.*

> **Вправа:** Дві з цих іконок мають однаковий колір. Зістав кожну пронумеровану іконку з тим, що вона означає.

## GitHub checks з першого погляду

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

**Alex Tutor:** Повернімося до #137. Позначка біля його назви це червоний хрестик. Відкрий pull request, і кожна перевірка покаже свій результат.

```text
Перевірки на #137
- [All checks have passed] build: Successful: успішно
- [Some checks were not successful] test: Failing: впав 1 тест на зображення товарів
- [Skipped] preview: Skipped: для оновлень залежностей preview не запускають
```

**Alex Tutor:** Чотири результати, які варто знати (станом на 2026 рік). Зелене коло з галочкою: пройдено. Червоне коло з хрестиком: впало. Жовта крапка: у черзі або ще триває. Сірий: пропущено або нейтрально, перевірка не запускалася чи не дала вердикту.

**Sofia:** Тобто пропущена перевірка це не пройдена перевірка.

**Daniel:** Ні, і це підступно. Станом на 2026 рік пропущена задача не блокує мердж, навіть коли вона обов'язкова. «Пропущено» означає, що цю частину ніхто не перевіряв.

![Автомобіль проїжджає пропускний пункт із порожньою будкою й піднятим шлагбаумом; інспектора всередині немає.](https://productovi.com/courses/git-for-product/inline/icons-and-colours-illustration-4.webp)

*Пропущена перевірка означає, що ніхто не дивився, а не що все гаразд.*

**Daniel:** А червоний хрестик на #137 означає, що оновлення від бота зламало тест у його власній гілці. Із живим сайтом усе гаразд.

> **Вправа:** Чотири результати перевірок без підписів. Яка іконка означає, що перевірка ще триває?

**Alex Tutor:** Daniel назвав пропущені перевірки підступними. Перевірмо чому.

> **Вправа:** На #137 перевірка `preview` пропущена, а не впала. Отже, цю частину перевірено, і дивитися на неї нікому не треба.

## Вердикти рев'ю

**Alex Tutor:** У рев'ю теж є іконки. На сторінці pull request вони стоять біля імені кожного рев'юера в бічній панелі.

```text
Вердикти рев'ю
- [Approved]: Галочка: рев'юер каже, що можна зливати
- [Changes requested]: Файл із плюсом і мінусом: спершу потрібні зміни
- [Commented]: Хмаринка діалогу: коментарі без вердикту
```

**Alex Tutor:** У списку рядок підсумовує це словами: «Review required» (схвалення ще немає), «Approved» або «Changes requested».

**Sofia:** #137 каже «Review required». Бота ще ніхто не схвалив.

**Daniel:** Так. А станом на 2026 рік маленька крапка біля імені рев'юера означає, що запит досі чекає: рев'ю ще не було.

**Sofia:** Як моє ім'я на #134 учора зранку, ще до мого першого слова.

> **Вправа:** Ці іконки стоять біля імен трьох рев'юерів на pull request. Зістав кожну пронумеровану іконку з вердиктом рев'юера.

## Мітки: кольори команди

**Sofia:** А мітки? `bug` червона. Червоний означає «терміново»?

**Alex Tutor:** Мітки це місце, де колір з боку GitHub нічого не означає. Колір обирає той, хто створює мітку. Нові репозиторії отримують кілька стандартних, як-от червону `bug`, але Котокорм хоч завтра може зробити її рожевою.

**Alex Tutor:** Тож у мітки читай текст, а стан читай з іконки. Червона мітка `bug` на відкритому pull request означає просто відкритий pull request про баг.

**Daniel:** Наш набір невеликий: `bug`, `checkout`, `content`, `idea` і `dependencies`, яку Dependabot додає сам.

**Sofia:** Добре. П'ятдесят міток у дванадцяти кольорах були б просто шумом.

> **Вправа:** Pull request #137 має синю мітку `dependencies` і зелену іконку pull request ліворуч. Що відомо про його стан?

## Блок мерджу згори донизу

**Alex Tutor:** Тепер #134. Два схвалення, перевірки зелені. Daniel відкриває його, щоб змерджити, а кнопка мерджу досі сіра.

**Sofia:** Блок мерджу каже «This branch is out-of-date with the base branch» («гілка відстає від базової»), і поруч кнопка `Update branch`.

**Daniel:** Правило після моєї березневої пригоди. Відтоді `main` вимагає, щоб гілка не відставала перед мерджем. Моя відстає на три коміти: набір ласощів, #133 і #132.

**Alex Tutor:** `Update branch` («оновити гілку») мерджить `main` у його гілку: той самий напрямок, що й `Commit merge` у Emma в модулі 2. Це новий коміт, тож перевірки запускаються знову.

```text
Граф комітів, від найстарішого: fix/checkout-button після Update branch
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"
10. мердж-коміт 9e3b5d2: main змерджено в fix/checkout-button "Merge branch 'main' into fix/checkout-button" (виділено)
```

*Update branch приніс три нові коміти main у гілку мердж-комітом 9e3b5d2. Тепер гілка відстає на 0, а перевірки йдуть на 9e3b5d2.*

**Daniel:** Тепер перевірки тестують моє виправлення разом з усім, що потрапило в `main`, відколи я почав. Саме те, що я пропустив у березні.

> **Що може сказати блок мерджу (станом на 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**: конфлікти, див. модуль 2.
> - **All checks have passed**, **This branch has no conflicts with the base branch** і схвалення: кнопка мерджу стає зеленою.
>
> Точні формулювання з роками змінюються, а зміст ні.

> **Вправа:** Pull request #134, виправлення кнопки від Daniel, пройшов шлях від першого коміту до мерджу за три дні: у рев'ю попросили змін, двоє схвалили, а `main` тим часом пішла вперед. Розстав стани, через які він пройшов, від першого до останнього.

## Змерджений чи закритий pull request

**Alex Tutor:** За десять хвилин: усі перевірки пройдено, конфліктів немає, два схвалення. Кнопка зелена. Daniel натискає `Squash and merge`, а потім `Confirm squash and merge`.

```text
#134 і #131 після мерджу
- [Merged] Fix checkout button after cart edits #134: Змерджено в main як d51c7e8
- [Closed as completed] Checkout button stays grey after editing cart #131: Закрито як виконане завдяки #134
```

**Sofia:** #134 має іконку мерджу, а #131 закрилося саме: коло з галочкою. Дві форми, одна добра новина.

**Alex Tutor:** Не плутай ці два стани: **змерджений** pull request доніс свої коміти до `main`. **Закритий** (closed) завершили без мерджу, і з нього в код не потрапило нічого. У списку обидва лежать у `Closed`, тож дивись на іконку, а не на вкладку.

**Daniel:** У `main` це один коміт: «Fix checkout button after cart edits (#134)». Гілка видалилася сама, а деплой уже йде. Дай йому п'ять хвилин, а потім перевір живий сайт на телефоні.

**Alex Tutor:** І три питання з модуля 2: куди змерджено, коли і чи воно досі там? Сьогодні: у `main`, о 9:40, і так.

**Sofia:** Підтримка отримає сповіщення, що #131 закрито. А я допишу рядок, що все працює, щойно перевірю на сайті.

> **Вправа:** Pull request #134, в описі якого написано `Fixes #131`, щойно злили в `main` через squash-мердж. Котокорм автоматично викладає кожен мердж у `main` і видаляє змерджені гілки. Які твердження правильні одразу після мерджу? Познач усе, що підходить.

## Скажи без кольорів

**Alex Tutor:** Ще одна звичка. Колега з відділу продажів, який має порушення кольорового зору, питає в чаті, що там із #137.

**Sofia:** Оновлення від бота з тестом, що впав.

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

**Daniel:** Бонусні бали, якщо скажеш, хто має діяти.

> **Вправа:** Колега з порушенням кольорового зору питає, що там із #137. Опиши його стан у 2–3 реченнях без жодних слів про колір: pull request, перевірки, рев'ю і хто діє далі.

## Оновлення на п'ятницю

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

**Sofia:** Зі списків, а не з пам'яті.

**Daniel:** І, будь ласка, не кажи «та сіра» при CEO. Банер Emma це чернетка, а не загадка.

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

> **Вправа:** Напиши п'ятничне оновлення статусу від Sofia для продуктової зустрічі на основі списків, наведених у цьому завданні.

**Alex Tutor:** Це модуль 3: pull request вкладка за вкладкою, рев'ю з продуктового боку і будь-який стан з першого погляду.

**Sofia:** А кнопка оформлення працює в мене на телефоні. Підтримка вже подякувала.

**Daniel:** Наступний модуль: як команди організовують усі ці гілки. У нас просто. А в деяких командах є ціла гілка `develop` і релізи з номерами версій.

- Попередній урок: [Рев'ю pull request очима PM: коментарі, пропозиції, approve](https://productovi.com/uk/courses/git-for-product/reviewing-as-a-pm.md)
- Наступний урок: [GitHub flow: малі гілки, швидкі мерджі](https://productovi.com/uk/courses/git-for-product/github-flow.md)

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