GitHub RSS Feeds for Releases, Commits, and Tags

GitHub RSS feeds can follow repository releases, commits, tags, and public user activity in a feed reader. The public feed addresses use Atom XML, which many readers accept alongside RSS.

For Hugo releases, add this URL to your reader:

https://github.com/gohugoio/hugo/releases.atom

Releases are a good starting point when you want published updates rather than every development commit. A busy repository’s commit stream can be much noisier than its release feed.

GitHub RSS feeds use different addresses for each timeline

These patterns identify the common public feeds:

Replace the uppercase placeholders. A repository page, its releases feed, and its tags feed describe different things, even when some entries refer to the same version.

The examples below use a public repository. Private repository access is a separate concern; do not assume that a feed reader has the permissions of the browser tab beside it.

GitHub’s feeds API documentation describes its public and authenticated timeline feeds. Keep the public URL patterns as a convenience to verify, rather than treating them as an immutable integration contract.

Pick releases or tags based on what you want to notice

A release feed is useful for a project that publishes release entries. A tags feed follows tags, which may have a different purpose or cadence in that repository.

For the same Hugo repository, compare:

https://github.com/gohugoio/hugo/releases.atom
https://github.com/gohugoio/hugo/tags.atom

Choosing both can produce overlapping updates in your reader. Start with one and add the other when it contributes something you actually need.

A tag is not automatically a review of what changed. Follow the project’s own release notes and versioning conventions before turning a feed entry into a decision to upgrade.

Make the branch explicit for commit feeds

The default-branch feed can be useful when the repository’s default is the timeline you want:

https://github.com/gohugoio/hugo/commits.atom

For an explicit branch, include its name:

https://github.com/gohugoio/hugo/commits/master.atom

master is the branch used in this concrete example. Other repositories may use main or another branch, so inspect the repository instead of copying that part blindly.

An explicit branch makes the subscription’s intent visible. The default-branch address is more convenient when you deliberately want to follow whichever branch the project designates as its default.

Neither feed should be treated as a complete historical export. A reader receives the entries the feed currently exposes, not an unlimited backup of the repository.

Check the response when a reader rejects the URL

Download a public feed for inspection:

curl -fsSL https://github.com/gohugoio/hugo/releases.atom -o /tmp/hugo-releases.atom

A feed response should contain XML with an Atom feed element, not a login page or an HTML error document. The Atom specification describes that document structure.

If a reader reports an error, check the repository owner, repository name, branch, and returned response. A request that redirects to a sign-in screen has not become a valid feed just because the browser can display something.

For an intermittent server error, distinguish a failed request from a permanently invalid URL. Retrying a read-only fetch can help identify that difference; repeatedly changing tokens or publishing private feed links cannot.

Keep private activity URLs private

GitHub’s feeds API can provide authenticated timelines. A private feed URL may carry credentials or a token, so obtain it through the account’s supported interface or documented API instead of constructing a guessed secret-bearing address.

Do not paste a private feed URL into a public blogroll, issue, screenshot, or repository. A hosted reader also becomes another service holding that address; consider whether that fits the sensitivity of the feed.

For following a public project, I would prefer its public release feed. It avoids introducing an account credential just to hear about a new version.

Keep feeds separate from the notifications inbox

An activity feed follows its particular timeline. It is not a guarantee that mentions, review requests, or every notification you need will appear there.

For notification-specific workflows, GitHub documents a separate notifications API. Pick the source that represents the information you need instead of assuming every GitHub update has the same feed.

Feed readers work well for quiet monitoring. Follow releases when you want upgrade news, an explicit branch when you need development activity, and keep the account’s notification controls for work that requires a direct response.

← Back to all articles