Open any developer's GitHub profile and the first thing you see, below their name and bio, is a grid of small coloured squares. Seven rows tall, fifty-three columns wide, the colours stepping from pale grey through four shades of green. It is called the contribution graph, and almost every working developer on Earth has one. Most of us look at it every week. Very few of us could explain, in plain language, what it is actually counting.
This is that explanation.
What the squares are
Each square is one day. The grid covers the last full year of activity, ending today, so the column on the far right is this week and the column on the far left is roughly fifty-two weeks ago. Within a column, the top row is Sunday and the bottom row is Saturday, which is one of the small things that annoys developers from countries where the week starts on Monday.
The colour of each square reflects the number of "contributions" GitHub counted on that day. A grey square is zero. The four greens, from pale to dark, are scaled relative to the developer's own busiest day in the period, not to some global benchmark. A first-year developer with one or two daily commits will see dark green at the same activity level a staff engineer would barely register.
What counts as a contribution
This is the part most people get wrong. Two actions always count: creating a new repository, and forking a repository. Several more count only when they happen in a standalone, non-fork repository: opening an issue, proposing a pull request, submitting a pull request review, opening a discussion, answering a discussion, and committing to the default branch or the gh-pages branch.
There are several things people assume count, but do not.
Pushing a branch does not count by itself. Only commits on the default branch are tallied, so a feature branch with thirty commits contributes nothing until it is merged. Comments on issues do not count. Reactions, stars, and follows do not count. Wiki edits do not count. Force-pushing rewritten history does not retroactively change the graph either, which is why developers who rebase aggressively sometimes appear less productive than they are.
What does not appear, even though it happened
The graph famously hides private work. By default, only public-repository activity is shown, and private contributions do not appear at all. A developer can opt in to surface them, in which case they appear as anonymized squares with no repository or commit detail. A consultant who spent the entire year shipping production code for a private client can have a graph that looks like a six-month sabbatical.
It also hides anything that did not happen on github.com. Commits to a self-hosted GitLab, to Bitbucket, to a corporate Gerrit instance, or to a personal Sourcehut all leave no mark. The graph is not a record of work. It is a record of a specific subset of work, made on a specific platform, attributed to a specific email address that GitHub recognises as belonging to that account.
That last detail trips up more developers than any other. If your local Git client is configured with an email address that is not on your GitHub account, your commits will land in the repository correctly but will not be attributed to you on the graph. There is a small army of developers who have lost a year of squares this way and only discovered it during an annual review.
A brief history
The contribution graph was introduced in 2013. It was a simple visualisation borrowed from a then-fashionable corner of data design called the calendar heatmap, where each day of the year was rendered as a coloured cell in a calendar-shaped grid. The original was a one-year view, the same as today. It has been redesigned twice since, mostly to improve the colour palette for colour-blind users, and once to add support for the dark theme.
The graph was not designed as a productivity tracker. It was designed as a way to visualise the rhythm of open source work, which tends to come in bursts: a free weekend, a holiday week with too much time, the slow accumulation of small fixes. Within a year of launch, recruiters had started using it as a proxy for hireability, which is not what its designers intended and has caused a measurable amount of harm to developers who do their best work in private repositories or in non-Git workflows.
What the shape reveals
For all its blind spots, the graph reveals more than it should. A long horizontal stripe of dark green, sustained across many months, is almost always either a bot, a streak-maintenance script, or someone who is heading for burnout. A graph that brightens slowly across the year and dims toward the end is often a junior developer growing into the work. A grid that is uniformly bright Monday through Friday and grey on weekends belongs to someone with healthy boundaries, which is rarer than it should be.
The most interesting graphs, though, are the ones with the dark spaces. The two-month gap that was a sabbatical. The half-year quiet that was a new baby. The clean line where someone changed jobs. The graph hides the work but accidentally records the life around it.
What you can do with it
You can look at it. You can also pin specific repositories beneath it. You can show or hide private contributions. You can change the default branch detection. You can connect it to other services through the GitHub API. And you can take it off the screen.
The graph fades the moment you scroll past it. It updates within a day, and the top view is a rolling twelve-month window, so the exact composition you saw last December has already moved on as this year advanced. GitHub keeps the underlying per-year data, reachable through the year selector on the side of the profile, but it gives you no fixed, framable artifact of a particular year. The data persists. The keepsake does not. If you want a record of a particular year of your work, the only reliable way to get one is to take a snapshot yourself.
This is the part of the explainer where we mention that we do this. Codex Stellarum turns the same data the graph is built on into a vintage astronomical chart. Every commit is a star, every quiet week is a dark space, and the whole year of work is rendered as something that looks like it was printed in 1640. The digital download is £10. Physical prints start at £25. You enter a GitHub username and the rest assembles itself.
The graph is a remarkable piece of small design. It has, almost by accident, become the most-seen visualisation of personal work in modern software. It is also, on its own, a passing view. The squares dim, the year rolls forward, and the particular shape you knew gives way to a new one. Whether you want to keep yours is, in the end, a question about what you think the work was for.