GitHub Releases Versus Commits: What Each Activity Measure Tells You

A commit and a GitHub release are different records. A repository can accumulate commits without publishing a release, and a release can package work collected over a longer period. Counting them together obscures the distinction between code changes and a published release record.

For startup scouting, keep separate observations and ask what each actually measures. Neither establishes revenue, headcount, customer adoption or fundraising. The site's methodology describes public activity inputs, but a manual release review should not be presented as a verified component of the site's score unless that implementation has been checked.

Start with the object you are counting#

The GitHub releases API returns release records. GitHub explicitly says the list does not include ordinary Git tags that have not been associated with a release. An empty release list therefore does not prove there are no tags, commits or product updates.

The repository statistics endpoint describes commit activity grouped by week. It also says statistics exclude merge commits. That is a counting rule for the endpoint, not a universal definition of all development activity.

Write down the object and source before comparing two charts. "Published release records in this window" and "commits counted by this endpoint" are clear measurements. "Shipping speed" needs more explanation and should not be inferred automatically from either number.

Choose the relevant timestamp#

Release records include `created_at` and `published_at`. The documentation for the latest-release endpoint says `created_at` is the date of the commit used for the release, not the date it was drafted or published.

If your question is when a release was published, inspect the publication field rather than assuming creation time answers it. Keep a missing publication timestamp missing. Record the timestamp field used in the calculation so another analyst can reproduce the result.

The latest-release endpoint also describes excluding draft and prerelease releases. That is not the same population as a complete release list. Decide whether prereleases belong in your analysis, record the choice, and apply it consistently to both periods.

Compare timelines, not interchangeable totals#

A useful manual table has separate columns for release identity, publication time, tag name, prerelease status, and the commit activity observed over a defined window. Preserve links returned by the source so a reviewer can inspect the release notes.

Do not divide commits by releases and call the result developer productivity. A different release process can change that ratio without changing the quality or amount of work. A repository's public releases may also cover only one part of a larger product.

Instead, ask bounded questions:

Was a release published during the observed interval?

Is it marked as a prerelease?

What do the release notes actually claim changed?

Does the commit window cover the same repository and dates?

Did the collection include all relevant pages?

These questions produce a checkable observation rather than a business conclusion.

Read release notes as claims to inspect#

Release notes can describe fixes, features or compatibility changes. They are useful context, but their wording does not prove that customers adopted the change or that a deployment reached every user.

Keep the distinction visible in your notes. Write "release notes describe a new integration" rather than "the company gained integration customers." If an outcome matters, seek outcome-specific evidence outside GitHub.

The same caution applies to commit messages. A message saying "launch" is not itself proof of a commercial launch. Public-code artifacts explain what is visible in the repository, not everything happening inside the company.

Avoid collection shortcuts#

The pagination documentation explains that large responses can be split across pages. Follow the returned next-page links instead of assuming the first page is the entire history. Record whether the collection completed.

The API versioning guide explains how to request a version explicitly. Keep the version in the snapshot alongside the repository identifiers and timestamp fields.

If a statistics request is pending, do not substitute zero commits next to a real release count. Missing data and observed inactivity are different states. Preserve the uncertainty and postpone the comparison if the gap could change it.

Put the result into a scouting workflow#

Use the trending view to select names worth inspecting, then examine their actual public repositories. The blog provides practical context, while the measurement record should contain your own dates, scope and caveats.

A defensible conclusion might read: "This repository published a non-prerelease release in the selected window, and its public commit count changed under the stated counting rule." That is less dramatic than "the company is taking off," but it is an observation another person can check.