What Are GitHub Contributions and How Are They Counted?

Updated

GitHub contributions are the activity events GitHub records on your profile and contribution graph, primarily commits, pull requests, issues, and code reviews. They are counted when they meet GitHub's conditions: the commit is on the default branch (or gh-pages), is associated with an email tied to your account, and falls within the displayed time window. Contributions measure activity, not skill — a high count says someone shows up often, not that their code is better. Git City uses this same public activity data to render each developer as a building in a 3D pixel-art city, so understanding what counts helps you read both your graph and the city correctly.

What counts as a contribution

GitHub's contribution graph tracks a defined set of events. The main ones:

  • Commits — pushed to the default branch of a repository, or to the gh-pages branch.
  • Pull requests — opened, and also merged pull requests you authored.
  • Issues — opened.
  • Code reviews — submitting a review on a pull request.
  • Discussions — starting or answering in repositories that have Discussions enabled.

Each qualifying event adds to the daily square on your graph. The graph is a calendar heatmap: darker squares mean more events that day, and the yearly total is the number most people quote.

What does not count

This is where most confusion comes from. Common activities that stay off the graph:

Activity Counts? Why
Commits on a non-default branch No Only default branch (and gh-pages) commits count
Commits with an unverified or unlinked email No GitHub can't attribute them to your account
Commits in a fork you haven't merged upstream No Fork activity is excluded until it lands in the parent
Private repo activity Only if enabled Private contributions show as counts, not details, when you opt in
Issues you comment on No Only issues you open count
Stars, follows, wiki edits No Not part of the contribution model

Two conditions trip people up most often: branch and email. A commit pushed to feature/login won't appear until it merges to main. A commit made with a work email not added to your GitHub account is invisible to your graph even though the code is public.

Commits, PRs, and reviews are not equal

A single pull request can generate several contribution events — the PR itself, each review, and the merge — while a day of solo commits might produce dozens of commit squares. This means raw totals aren't comparable across workflows. Someone who works through reviewed PRs will often show fewer commits but more total events than someone committing directly to main. When you compare two profiles, compare like with like: commit-heavy vs. review-heavy work styles produce very different graphs for similar effort.

Contribution count is not a skill score

The graph answers "how active was this person, and when?" It does not answer "how good is this person?" A few things it can't see:

  • Whether the commits were a one-line typo fix or a major feature.
  • Whether the work was solo or collaborative.
  • Whether the person was on vacation, at a job that doesn't use GitHub, or contributing to projects hosted elsewhere.
  • Quality of reviews, issue reports, or design discussion.

Treat the graph as a rhythm indicator — streaks, gaps, bursts — rather than a ranking. For hiring or collaboration decisions, read the actual repositories and PR discussions.

How Git City turns contributions into a city

Git City (thegitcity.com) visualizes GitHub users as buildings in a 3D pixel-art city you can fly through. The mapping is intuitive: your contribution activity informs the presence and scale of your building, so more active developers appear as more prominent structures, and the city as a whole becomes a navigable map of open-source activity. The site describes itself as "a global city of GitHub developers" with a search function to find yourself.

Two practical implications follow from how contributions are counted:

  1. Your building reflects public, attributable activity. Commits made with an unlinked email or on unmerged branches won't feed the visualization any more than they feed your graph.
  2. The city is a discovery tool, not a ranking. Because contribution counts vary by workflow, use the city to find developers and then visit their actual profiles and repos.

The page shows a live/sleeping indicator and graphics quality settings, suggesting the visualization is interactive rather than a static image — worth exploring directly rather than relying on a description.

Check your own contributions and fix gaps

If your graph or your Git City presence looks thinner than expected, work through this checklist:

  1. Open your profile's contribution graph and click a day to see the events listed. GitHub shows exactly which commits, PRs, and issues were counted.
  2. Verify your commit emails. In GitHub settings, check the emails associated with your account; add any work or personal addresses you commit with. Then confirm commits show as "Verified" or at least linked to your username.
  3. Check the branch. Confirm the commits landed on the repository's default branch. Merged feature branches count; open ones don't.
  4. Enable private contributions if you want private work to appear as anonymous counts on your public graph.
  5. Wait for the cache. New activity can take up to about a day to appear on the graph; the underlying events are recorded immediately.
  6. Revisit the visualization. Once your public activity is correctly attributed, reload Git City and search for your username to see the updated building.

If a commit still doesn't appear after these steps, the most likely cause is an email mismatch — the commit exists publicly but GitHub has no way to credit it to you.