Updated July 19, 2026 · WarmStars
Short answer
You watch a repo with the Watch button at the top right of its page. Watching is a subscription: GitHub notifies you when things happen there, new releases, issues, discussions. Starring is different. A star is a public bookmark and a quiet vote. Watching is mostly private and mostly about notifications. Pick Custom, then Releases only, when you just want to know the day a dependency ships.
There is a person, somewhere, who signed up for the mailing list of a bakery three states away, purely so they would know the morning the sourdough came back. Watching a repository is that same small hopeful act, pointed at code. You are asking a project to tell you when something happens.
Go to the repo. Say it is acme/rocketdb. At the top right, above the file list, three buttons sit in a row: Watch, Star, and Fork. Click Watch. A little menu drops open, and this is where most people stop reading and shouldn't, because the menu is the whole point.
A fresh watch defaults to Participating and mentions, which is quieter than the word watching suggests. You are not signed up for everything that moves. You are signed up for the threads you have already spoken in, and for the moments someone types your username. That is it, until you tell it otherwise.
The menu gives you four settings, and they run from polite to firehose. Participating and mentions is the default and the gentlest: you hear back only where you are already involved. It is the setting most people should leave alone.
All Activity is the firehose. Every issue, every pull request, every comment on acme/rocketdb lands in your notifications. It is right for a repo you maintain and wrong for almost everything else. Ignore is the mute button: no notifications at all, not even mentions, which is handy for the noisy repo you were auto-subscribed into and cannot seem to escape.
Custom is the one worth learning. It opens a short checklist, Releases, Issues, Pull requests, Discussions, Security alerts, and lets you tick only what you want. For a dependency, tick Releases and nothing else. Now the project tells you the day a new version ships and keeps its mouth shut the rest of the year. That, quietly, is what most people wanted from Watch all along and never found.
Three buttons, three verbs, and people blur them constantly. Watch is a subscription. Star is a bookmark. Fork is a copy. Same row, entirely different jobs.
A star is a bookmark you can find again and a small public nod that says this was worth remembering. The count is a headline number, an aggregate, how many. It tells you a repo is popular and nothing about who. The people are where the value sits, and if you want the difference spelled out, see what a GitHub stargazer is.
A fork is a full copy of the repo dropped into your own account, so you can change things without touching the original. Watching notifies you. Starring remembers. Forking hands you the keys to your own version. If forking is the part you are fuzzy on, here is how to fork a repo.
Unwatching is the same button that got you here. Click Watch on acme/rocketdb again and set it back to Participating and mentions, or Ignore, or Unwatch outright. Nothing dramatic happens. The notifications simply stop.
For the bigger clean, go to github.com/watching. It is the full list of every repo you ever subscribed to, including the dozen you forgot about, and you can unsubscribe straight from the page. Most people who feel buried in GitHub email have never once opened it. Ten quiet minutes there fixes a lot.
Honestly, not much. GitHub keeps a watcher count and a watchers page, but as a read on who actually cares about your project, it is thin. A watch can mean deep investment, or a one-time notify me when this ships and then a person who never thinks about you again. It is a utility signal, not an affection one.
A star is the warmer read. When someone stars acme/rocketdb, they are raising a hand in public: I like this, I want to keep it. For your own repo, those stargazers are the closest thing you have to a list of people who already chose you, which matters far more than a watcher tally. If you are new to reading that list, start with seeing who starred your repo.
That is the useful move for a maintainer: stop counting and start looking at who. A tool like the stargazer checker turns your own stargazer list from a number into named people, from public data only, so the developer who starred you, say dev-priya, becomes someone you can actually reach, with a public email for many of them. Your first users are usually already standing in that list. Watching tells you when the code changes. The stars tell you who showed up.
How to Get Your First Users for an Open-Source Project
First users come from narrow, warm, manual outreach. Where to find them and how to keep them.
How to see who starred your GitHub repo
What GitHub’s 2026 restriction changed, how owners still see their own stars, and what the list hides.
Did GitHub remove the stargazers page in 2026?
GitHub locked the stargazer list to admins on June 30, 2026. What still works, and how owners still see their own stars.
Free to start. Two scans a month, no credit card.