# Icons, colours and checks: what every GitHub state means > Read pull request status, issues, GitHub checks, reviews, labels and the merge box at a glance: what every icon and colour means, merged vs closed, and how to tell states apart by shape and text, not colour alone. - Course: [Git and GitHub for Product People](https://productovi.com/courses/git-for-product.md) - Module: Pull requests - Lesson 9/15, ~45 min - Source: https://productovi.com/courses/git-for-product/icons-and-colours ## Pull request status in the morning list **Alex Tutor:** Morning. Another day on CatChow's product team: Daniel is about to merge #134. Before he does, open the repository's `Pull requests` tab and just look at the list for a minute. ```text Pull requests in catchow/website: Open - [Open] Fix checkout button after cart edits #134: by Daniel · Approved · checks passed · bug, checkout - [Draft] Add autumn sale banner #136: by Emma · Draft · content - [Open] Bump image-optimizer from 2.3.0 to 2.4.1 #137: by dependabot · Review required · 1 check failed · dependencies ``` **Sofia:** Three rows, each starting with an icon: two green, one grey. And a small mark next to each title. **Alex Tutor:** The icon on the left is the pull request status. As of 2026: green for open, grey for draft, purple for merged, red for closed. The small mark by the title is the result of the checks. **Sofia:** Where are the merged ones, though? #133 and Emma's #132 aren't here. **Alex Tutor:** The list shows `Open` by default. Merged and closed pull requests both sit under `Closed`, right next to it. **Daniel:** And #137 is from Dependabot, a GitHub bot that opens a pull request when a library we use gets a new version. Oscar looks after those. > **Exercise:** These are the four pull request state icons, without their labels. Match each numbered icon with its state. ## Shape first, colour second **Sofia:** Honestly, in the sun on my phone the purple and the grey look almost the same. **Alex Tutor:** Then read the shape. Open: the pull request icon, two dots joined by lines with an arrow. Draft: the same icon with a dashed line. Merged: two lines joining into one. Closed: the pull request icon with a small cross. ![In bright sun, a person squints at a phone whose status icons differ by shape: a plain circle, a circle with a tick and a crossed circle.](https://productovi.com/courses/git-for-product/inline/icons-and-colours-illustration-2.webp) **Alex Tutor:** About 1 in 12 men and 1 in 200 women see some colours differently, most often red and green. That's why GitHub pairs every state colour with a shape and a word. **Daniel:** GitHub also has colour-blind friendly themes in its appearance settings, which swap red and green for other colours. So a colleague's screen may not match yours at all. **Alex Tutor:** So when you write about states, name them. "#133 is merged", "#138 was closed as not planned". Never "the purple one". > **Exercise:** This is the `Closed` view of the pull request list. Every pull request in it was closed without its changes reaching `main`. **Alex Tutor:** Now put that into a real chat message. > **Exercise:** A sales colleague asks in chat how the delivery changes are going. Which reply works for everyone, whatever their screen or eyesight? ## Issues have their own states **Alex Tutor:** Now the `Issues` tab. Issue icons are circles. An open issue is a circle with a dot in the middle, green. ```text Issues in catchow/website - [Open] Checkout button stays grey after editing cart #131: opened by support · bug, checkout · linked pull request #134 - [Open] Test an orange checkout button #135: opened by 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 is the finance issue from module 1. Purple, with a tick inside the circle. **Alex Tutor:** Closed as completed: the work is done. Purple means the same as on a merged pull request, finished. #138 was closed as not planned: grey, a circle with a slash. **Daniel:** That was the idea of showing prices in euros. We decided against it, so we closed it as not planned instead of pretending it was done. GitHub asks for the reason when you close an issue. **Sofia:** So both are closed, but only one means someone did the work. **Alex Tutor:** For a PM that's the difference between "shipped" and "dropped". When you report on issues, never count the two together. ![Two closed boxes: one with a ribbon and a tick seal is carried out to customers; the other, with a cross seal, is set aside on a back shelf.](https://productovi.com/courses/git-for-product/inline/icons-and-colours-illustration-3.webp) *Both are closed, but only one means the work was done.* > **Exercise:** Two of these icons share a colour. Match each numbered icon with what it means. ## GitHub checks at a glance **Alex Tutor:** **GitHub checks** are the automated runs GitHub shows on every commit of a pull request, such as building the site or running the tests. Each one reports a status, and a team can make some of them required status checks, so a pull request can't merge while one of them fails. **Alex Tutor:** Back to #137. The mark next to its title is a red cross. Open the pull request, and each check shows its own result. ```text Checks on #137 - [All checks have passed] build: Successful - [Some checks were not successful] test: Failing: 1 test on product images - [Skipped] preview: Skipped: no previews for dependency updates ``` **Alex Tutor:** Four results to know, as of 2026. A green circle with a tick: passed. A red circle with a cross: failed. A yellow dot: queued or still running. Grey: skipped or neutral, the check didn't run or gave no verdict. **Sofia:** So a skipped check isn't a passed check. **Daniel:** No, and it's sneaky. As of 2026 a skipped job doesn't block the merge even when it's required. Skipped means nobody tested that part. ![A car rolls through a checkpoint with an empty booth and a raised barrier; no inspector is inside.](https://productovi.com/courses/git-for-product/inline/icons-and-colours-illustration-4.webp) *Skipped means nobody looked, not that everything is fine.* **Daniel:** And the red cross on #137 means the bot's update broke a test on its own branch. The live site is fine. > **Exercise:** Four check results, without their labels. Which icon means the check is still running? **Alex Tutor:** Daniel called skipped checks sneaky. Let's see why. > **Exercise:** On #137 the `preview` check shows as skipped, not failed. So that part has been checked and nobody needs to look at it. ## Review decisions **Alex Tutor:** Reviews have icons too. On the pull request page they sit next to each reviewer's name in the sidebar. ```text Review decisions - [Approved]: A tick: the reviewer says it can be merged - [Changes requested]: A file with plus and minus: changes are needed first - [Commented]: A speech bubble: comments, no verdict ``` **Alex Tutor:** On the list, the row sums it up in words: "Review required" (no approval yet), "Approved" or "Changes requested". **Sofia:** #137 says "Review required". Nobody has approved the bot yet. **Daniel:** Right. And as of 2026 a small dot next to a reviewer's name means the request is still waiting: they haven't reviewed yet. **Sofia:** Like my name on #134 yesterday morning, before I said a word. > **Exercise:** These icons sit next to three reviewers' names on a pull request. Match each numbered icon with the reviewer's decision. ## Labels: the team's colours **Sofia:** And the labels? `bug` is red. Does red mean urgent? **Alex Tutor:** Labels are where colour means nothing on GitHub's side. Whoever creates a label picks its colour. New repositories start with a few defaults, like a red `bug`, but CatChow could make it pink tomorrow. **Alex Tutor:** So read a label's text, and read the state from the icon. A red `bug` label on an open pull request is simply an open pull request about a bug. **Daniel:** Our set is small: `bug`, `checkout`, `content`, `idea`, and `dependencies`, which Dependabot adds by itself. **Sofia:** Good. Fifty labels in twelve colours would be just noise. > **Exercise:** Pull request #137 has a blue `dependencies` label and the green pull request icon on the left. What do you know about its state? ## The merge box, top to bottom **Alex Tutor:** Now #134. Two approvals, green checks. Daniel opens it to merge, and the merge button is still grey. **Sofia:** The merge box says "This branch is out-of-date with the base branch", with an `Update branch` button. **Daniel:** The rule from my March adventure. Since then `main` requires branches to be up to date before a merge. Mine is three behind: the cat treats bundle, #133 and #132. **Alex Tutor:** `Update branch` merges `main` into his branch: the same direction as Emma's `Commit merge` in module 2. It's a new commit, so the checks start again. ```text Commit graph, oldest first: fix/checkout-button after Update branch 1. commit f02a6d4 on main "Update FAQ answers" 2. branch fix/checkout-button starts from commit f02a6d4 3. commit 3a9d1c4 on fix/checkout-button "Reproduce bug in a test" 4. commit 8be2f70 on main "Add cat treats bundle" 5. commit b7e4a05 on fix/checkout-button "Re-enable button after cart edits" 6. commit 6f2c8a1 on main "Raise free-delivery threshold to 1000 UAH (#133)" 7. commit a7d93e4 on main "Rewrite delivery page copy (#132)" 8. commit c2d7f90 on fix/checkout-button "Update checkout hint copy" 9. commit f7a2b61 on fix/checkout-button "Restore checkout button colour" 10. merge commit 9e3b5d2: main merged into fix/checkout-button "Merge branch 'main' into fix/checkout-button" (highlighted) ``` *Update branch brought the three new commits of main into the branch with merge commit 9e3b5d2. The branch is now 0 behind, and the checks run on 9e3b5d2.* **Daniel:** Now the checks test my fix together with everything that reached `main` since I started. Exactly what I skipped in March. > **What the merge box can say, as of 2026** > > - **Review required**: no approving review yet. Blocked. > - **Changes requested**: a reviewer asked for changes. Blocked. > - **Some checks were not successful**: a check failed. Blocked if the check is required. > - **Some checks haven't completed yet**: checks are running. Wait. > - **This branch is out-of-date with the base branch**: `Update branch` (when the rules require it). > - **This branch has conflicts that must be resolved**: see module 2. > - **All checks have passed**, **This branch has no conflicts with the base branch** and an approval: the merge button turns green. > > The exact wording drifts from year to year; the meaning doesn't. > **Exercise:** Pull request #134, Daniel's checkout fix, went from his first commit to a merge over three days: a review asked for changes, two people approved, and `main` moved on in the meantime. Put the states it went through in order, from the first to the last. ## Merged vs closed pull request **Alex Tutor:** Ten minutes later: all checks have passed, no conflicts, two approvals. The button is green. Daniel presses `Squash and merge`, then `Confirm squash and merge`. ```text #134 and #131 after the merge - [Merged] Fix checkout button after cart edits #134: Merged into main as d51c7e8 - [Closed as completed] Checkout button stays grey after editing cart #131: Closed as completed by #134 ``` **Sofia:** #134 has the merge icon, and #131 closed itself: a circle with a tick. Two shapes, same good news. **Alex Tutor:** Keep the two apart: a **merged** pull request brought its commits into `main`. A **closed** one was shut without a merge, and nothing from it reached the code. Both sit under `Closed` in the list, so read the icon, not the tab. **Daniel:** On `main` it's one commit: "Fix checkout button after cart edits (#134)". The branch deleted itself, and the deploy is running. Give it five minutes, then try the live site on your phone. **Alex Tutor:** And the three questions from module 2: merged into what, when, and is it still there? Today: `main`, 9:40, and yes. **Sofia:** Support will get a notification that #131 is closed. I'll add a line saying it's live once I've checked. > **Exercise:** Pull request #134, whose description says `Fixes #131`, has just been squash-merged into `main`. CatChow deploys every merge into `main` automatically and deletes merged branches. Which statements are true right after the merge? Select all that apply. ## Say it without colours **Alex Tutor:** One more habit. A colleague from sales, who is colour-blind, asks you in chat what's going on with #137. **Sofia:** The bot's update with the failing test. **Alex Tutor:** Describe its state in two or three sentences, with no colour words at all: the pull request, the checks, the review and what happens next. **Daniel:** Bonus points for saying who needs to act. > **Exercise:** A colour-blind colleague asks what's going on with #137. Describe its state in 2–3 sentences without any colour words: the pull request, the checks, the review, and who acts next. ## The Friday update **Alex Tutor:** Last task. On Friday you give a short update at the product meeting: what's live, what's stuck and why, what was dropped. **Sofia:** From the lists, not from memory. **Daniel:** And please don't say "the grey one" in front of the CEO. Emma's banner is a draft, not a mystery. **Alex Tutor:** Here is what the lists show on Friday morning. Write the update as you would say it at the meeting. > **Exercise:** Write Sofia's Friday status update for the product meeting, based on the lists shown with this task. **Alex Tutor:** That's module 3: a pull request tab by tab, a review from the product side, and every state at a glance. **Sofia:** And the checkout button works on my phone. Support has already said thank you. **Daniel:** Next module: how teams organise all these branches. Ours is simple. Some teams have a whole `develop` branch, and releases with version numbers. - Previous lesson: [Approve a pull request as a PM: comments and suggestions](https://productovi.com/courses/git-for-product/reviewing-as-a-pm.md) - Next lesson: [GitHub flow: small branches, fast merges](https://productovi.com/courses/git-for-product/github-flow.md) --- Productovi Learning. Free, no sign-up needed to read.