How released works
You need to know whether a commit or PR has made it into a released version, so you can depend on it, tell someone to upgrade, or say that it shipped. Paste it into released and you get the answer.
Know if you can depend on it
Before you pin a dependency, build on a fix, or tell users to upgrade, confirm it's actually in a published release. released gives you the first release that contains the commit or PR and the date it shipped, or tells you it hasn't shipped yet.
Tell anyone whether it shipped
A contributor asks if their merged PR has gone out. A customer asks if the fix is available. A teammate wants to confirm it before they announce it. Paste the PR or commit and you have the version to give them. It resolves a PR or MR to its merge commit for you, even when the PR was squashed or rebased.
No clone, any repo
It works from a URL on any public repo, including dependencies you've never checked out. GitHub and GitLab don't answer this in their web UI. The alternative is cloning the repo and running git describe --contains, which needs every tag fetched and prints v1.2.3~4^2 instead of a version number.
Share it, or let the badge update itself
Every lookup is a permalink. Paste it in a release note, an issue, or a Slack thread, and whoever opens it sees the same answer. Or add /badge.svg and embed a badge in a PR: it reads "not yet released" until the commit ships, then flips to the version on its own, so the PR always shows current status. From a terminal, npx git-released <commit-or-pr>.
Where it works
GitHub, plus GitLab: gitlab.com, GNOME, KDE, Debian (salsa), freedesktop, and Kitware. Self-hosted GitLab can be added.
Private repos
The web app reads public repos. For a private repo, use the command-line version with a token that can read it, like GITHUB_TOKEN=… npx git-released <commit-or-pr> (or a GitLab token per host). The token scopes and environment variables are in the private-repos docs.