How do you see who forked your GitHub repo?

There are two places, and they answer two different questions. The first is the fork count itself. On your repo header, next to the star and watch counts, GitHub prints a number with a small fork icon. Click it and you land on the forks page, github.com/acme/rocketdb/forks, a plain list of every account that made a copy, most recent first.

The second place is quieter and, to my ear, more useful. Open the Insights tab, then Network. GitHub draws a fork tree: your repo as the trunk, each fork as a line off it, with commits plotted along the way. A fork that never moved sits as a stub. A fork that kept committing stretches out. In one glance you can see which copies are alive.

So the list tells you who, and the network graph tells you which of them did anything. Keep both open, because a name on the /forks page and a name doing real work on the Network graph are not the same lead. Treating them as the same is the first mistake, and it is an easy one to make.

This part is worth saying plainly, because it changed. In 2026 GitHub restricted the stargazer list on repos you do not own or help maintain. The count still shows. The named roster of who starred became owner-only. If you have gone looking for a stranger's stargazers lately and hit a wall, that wall is the reason, and it is new. I go into what it means for owners in the 2026 stargazer page writeup.

Forks did not change. The fork list is public for any repo, yours or not. Anyone can open github.com/acme/rocketdb/forks and read every account that forked it, and the Network graph is public too. On the fork side you have more visibility into a stranger's repo than you now do on the star side. That asymmetry is recent, and it is the one fact most people miss.

For your own repo the distinction barely matters, since you can see your own stargazers and your own forkers either way. It matters most for how you read the wider signal: a public fork list is durable, a public stargazer list is not.

A fork is a heavier signal than a star, and it is worth being precise about why. A star is a bookmark. It costs one click and says, roughly, I want to find this again. A fork is a copy. The person wanted the code in their own account, usually because they meant to run it, change it, or build on it. That is intent with its sleeves rolled up.

Here is the catch, and it is a real one. The fork count is noisier than the star count, not cleaner. A good share of forks are single-PR forks: someone forked, fixed a typo, opened a pull request, and never touched it again. Others are mirrors, backups, or forks a bot made automatically. A raw fork number flatters you. dev-priya forking to ship three months of features and dev-priya forking to correct a broken link both add one to the same total.

This is exactly what the Network graph is for. It separates the forks that kept committing from the forks that flatlined on day one. When you want to know who is genuinely building on acme/rocketdb, read the lines that grew, not the length of the list. The list is how many. The graph is who mattered.

GitHub gives your repo three separate ways for a person to raise a hand, and they are not interchangeable. Read as depths of interest, lightest to heaviest, they go: watch, star, fork. Each answers a different question, and the honest move is to keep them apart.

A watcher asked to be told. Watching subscribes someone to activity on the repo, releases and issues and sometimes every thread, so a watcher is often closer to a real user than a casual star. A stargazer approved. A star is the cheap, public nod, the bookmark, the vote: the widest signal and the shallowest, which is not an insult, because breadth has its own worth. A forker acted. They took your code somewhere and did something with it.

So the fair verdict, since one is owed: none of the three is best, they answer different questions. If you want reach and momentum, count stars. If you want people paying ongoing attention, look at watchers. If you want the smallest, warmest set of people who cared enough to build, read the active forks. I keep the fuller stars-versus-forks comparison here, because the difference deserves more than a line.

All of this is still aggregate underneath, even the names. A fork list is a column of usernames. A count is a number. Neither is a person you can actually talk to yet, and the whole value sits in closing that gap: from acme/rocketdb has 800 stars and 120 forks to dev-priya, who forked you in March and has been shipping on it since.

As the owner, you are allowed to do this with your own audience, and only your own. You can open each forker or stargazer, read their public profile, find the ones with a company, a site, a public email for many of them, and decide who is worth a note. Done by hand across a few hundred accounts it is slow but honest work.

That is the gap WarmStars closes for a repo you own: it takes your own stargazers and forkers, public data only, and turns the roster into named people with the public details already gathered, so you spend your time on the conversation instead of the copy-paste. If you would rather stay manual, seeing who starred your own repo walks the by-hand version, and the free stargazer checker is a fine place to start.