How the GitHub contribution graph actually works

The contribution graph is the most-looked-at and least-understood element of a GitHub profile. It is a 53-week grid of squares, shaded by how much you did that day, and people read an enormous amount into it - discipline, productivity, employability.

Most of those readings are wrong, because the rules for what fills a square are narrower and stranger than they appear.

What counts

GitHub counts four kinds of activity as contributions:

1. Commits to the default branch or to gh-pages, in a repository you own or have push access to.
2. Opening a pull request.
3. Opening an issue.
4. Submitting a pull request review.

That is the whole list. It is short, and each item has conditions attached.

What does not count (and surprises people)

Commits to a non-default branch. If you spend three weeks on a feature branch and never merge, those commits do not appear until they land on the default branch.

Commits authored with an email GitHub does not recognise. This is the single most common cause of a mysteriously empty graph. If your local Git is configured with an email that is not attached to your GitHub account, your commits are attributed to nobody. You can fix this retroactively by adding the email to your account settings - the graph then backfills.

Commits in a fork. Work in a fork does not count until it is merged upstream or the fork is detached into its own repository. Given how much open-source contribution starts in a fork, this hides a lot of real work.

Comments. Replying on an issue or a pull request - often where the actual engineering judgement happens - counts for nothing.

Anything in a private repository, by default. Private work is excluded unless the account owner has explicitly turned on “Include private contributions on my profile”, which shows the activity as anonymous filled squares without naming the repository.

So a developer who spends a year doing code review, mentoring, and long-lived feature branches inside a private monorepo can have a nearly blank graph and an extremely productive year.

The colour scale is relative, not absolute

The five shades are not fixed thresholds. GitHub scales them against your own activity over the displayed period, using quantiles.

This means the darkest green on a profile with three commits a day and the darkest green on a profile with forty commits a day look identical. You cannot compare intensity between two people’s graphs - only the shape of each person’s distribution against themselves.

This is a sensible design decision that almost everyone misreads.

Streaks were deliberately de-emphasised

GitHub used to display current and longest streak counters directly on the profile. They were removed in 2016.

The reasoning was straightforward: the counters encouraged people to make meaningless daily commits to keep a number alive, and they penalised anyone who took a holiday, got ill, or simply worked in a way that batched effort. Streaks measured attendance, not contribution.

Third-party tools - including this one - still calculate them, because people find them interesting. They are worth reading as a curiosity rather than a performance metric.

Reading the shape instead

The useful signal in a contribution graph is not density, it is shape.

• A hard edge where activity starts or stops usually marks a job change, a move to a private codebase, or an email misconfiguration.
• Strong weekday bands with empty weekends suggests the account is used for professional work and the person has boundaries.
• Uniform density including weekends often indicates either a full-time open-source maintainer or automation committing on the account’s behalf.
• Sparse but sustained over many years is, for most hiring purposes, a better signal than a single dense year.

The timezone caveat

Contribution days are bucketed by UTC date, not your local date. For developers in Asia-Pacific timezones, evening work frequently lands on the following UTC day. If your late-night sessions appear on the wrong square, this is why.

What this means if you are being evaluated

If you are worried your graph undersells you, the fixes are mostly mechanical:

1. Check git config user.email on every machine you use, and make sure each address is registered on your GitHub account.
2. Turn on private contribution visibility if your employer permits it. It reveals volume without revealing anything about the code.
3. Merge your own branches rather than leaving long-lived work unmerged.
4. Do not manufacture activity. Anyone senior enough to be evaluating you can tell the difference between a year of work and a year of README whitespace commits, and the second one is worse than an empty graph.

And if you are the one doing the evaluating: open the repositories. The graph tells you when someone was active on this particular platform. It does not tell you whether they are any good.

See your own graph in context

The CV generator renders your full contribution year alongside your language distribution and top repositories, with current and longest streaks calculated from the same data. Seeing all three together tends to be more informative than the graph alone - a sparse year with three heavily-depended-upon libraries reads very differently from a dense year of small commits.