GitHub + deariary: your code becomes your diary
Open your GitHub profile. The contribution graph is there, a grid of green squares going back months. You can see that you worked on a given day. You can see that some days were busier than others.
But what did you actually do three Tuesdays ago? The graph cannot tell you. It shows volume, not content. A day with 12 commits could be a major feature launch or a long afternoon of dependency bumps. The squares are the same shade of green either way.
This is the problem deariary solves for your GitHub activity. Not whether you worked, but what you worked on, organized into something you can actually read back.
What the contribution graph misses
GitHub’s contribution graph counts commits, pull requests, issues, and code reviews. It tells you how active you were. It does not tell you:
- Which features you shipped that day
- What code review feedback you gave (or received)
- Which issues you discussed and what the context was
- How your work across multiple repositories connected into a single day
If you work across 3 or 4 repositories in a day, GitHub scatters that activity across separate timelines. There is no view that says “here is everything you did on March 5th, across all your repos, as a single narrative.”
That is what deariary produces every morning.
What deariary collects from GitHub
When you connect GitHub, deariary pulls your daily activity through the GitHub Events API. It collects four types of activity:
- Commits: the commit messages you pushed that day, with the repository name
- Pull requests: PRs you opened, reviewed, merged, or closed
- Issues: issues you created, commented on, or closed
- Code reviews: review comments you left on other people’s pull requests
deariary does not read your source code. It does not clone your repositories. It does not access private file contents. The data it uses is the metadata around your activity, not the code itself.
What deariary does NOT collect
This is worth stating plainly:
- No source code. Not a single line.
- No repository file trees or directory structures.
- No secrets, tokens, or environment variables.
- No private repository names (unless you explicitly grant access to private repos during OAuth).
- No data from organizations you have not authorized.
If you connect deariary with public-repo-only permissions, it sees only your public activity. The OAuth scope is visible during the connection flow, and you can revoke it from GitHub’s settings page at any time.
From scattered activity to a readable day
Here is where deariary is fundamentally different from looking at your GitHub profile.
Say you had a day where you pushed commits to a backend API repo, reviewed a PR on a frontend repo, and commented on an issue in a shared library. On GitHub, that activity lives in three different places. You would need to visit each repository and piece the timeline together yourself.
deariary pulls all of it into one diary entry, grouped by topic rather than by repository. The entry might read:
You worked on rate limiting for the API, pushing several commits across the backend and shared library repos. You also reviewed a frontend pull request for the new settings page, leaving feedback on the error handling approach. In between, you discussed the webhook retry issue and suggested a backoff strategy.
One day, one entry, all repos. The topics connect naturally because deariary sees the full picture of your day, not isolated per-repository activity.
Commit messages matter (but you knew that)
The quality of your diary entry depends heavily on the quality of your commit messages. This is not unique to deariary. Good commit messages help your team, your future self, and your diary.
Compare these:
| Commit message | What deariary can write |
|---|---|
fix bug | ”You fixed a bug.” |
fix: prevent duplicate webhook delivery when retry overlaps with scheduled sync | ”You fixed an issue where webhooks were being delivered twice when a retry coincided with a scheduled sync.” |
deariary works with whatever you give it. But descriptive commit messages produce diary entries that actually tell a story. If you already follow conventional commits or write messages for your team, your diary benefits with no extra effort.
GitHub alone vs. GitHub with other integrations
A GitHub-only diary reads like a work log. That is useful, but it is one-dimensional. The entry knows what you coded but not what else happened that day.
Add Google Calendar, and the diary knows you had a 1-on-1 with your manager between coding sessions. Add Slack, and it captures that your teammate thanked you for a quick code review. Add Steam, and your evening gaming session makes it into the entry too.
The contrast is noticeable. Here is how the same day reads with different integration combinations:
GitHub only:
You pushed 4 commits to the frontend repository, fixing a layout issue and updating test coverage. You merged one pull request.
GitHub + Google Calendar + Slack:
Your morning started with a team standup, followed by a focused coding session on the frontend. You pushed 4 commits fixing a layout issue and improving test coverage. After lunch you had a 1-on-1 with your manager about the Q2 roadmap. Your pull request got merged after a quick review, and your colleague mentioned in the channel that the fix resolved a customer-reported issue.
The second entry describes a day. The first describes a task list.
On the Free plan you can connect one integration, which is enough to try GitHub on its own. Upgrading to Basic (up to 5 integrations) lets you combine GitHub with the rest of your day. See pricing on deariary.com for details.
When GitHub activity is low
Not every day is a heavy coding day. Some days you are in meetings. Some days you are reading documentation or thinking through architecture. Some days you are on vacation.
On days with little or no GitHub activity, deariary simply has less to work with from that integration. If you have other integrations connected, they fill the gaps. If GitHub is your only integration, the entry will be short or may note that it was a quiet day.
This is honest behavior. deariary does not invent activity to fill space. If nothing happened on GitHub, the diary says so.
Setting it up
Connecting GitHub to deariary takes about 30 seconds:
- Go to app.deariary.com
- Open Settings and find the Integrations section
- Click GitHub and authorize with your GitHub account
- Choose whether to grant access to public repositories only or include private repositories
That is it. The next morning, your diary will include your GitHub activity from the previous day. No cron jobs, no API tokens to manage, no webhook configuration on your side.
A dev log you will actually want to read back
If you have ever worked on a side project, you know the feeling. Six months later you think “when did I add that feature?” or “how did I fix that auth bug?” You check the commit history, and it is a wall of hashes and one-line messages. The context is gone.
deariary turns your GitHub activity into a running dev log without any extra effort. Each diary entry records what you worked on that day in plain language: the feature you started, the bug you chased, the refactor you finally tackled. Weeks and months later, you can scroll back and relive the arc of a project.
For solo developers, this is especially valuable. There is no team Slack to search. There is no standup history. There is no one who remembers that you spent three days on a caching problem in November except you, and you have already forgotten. The diary remembers.
It also captures the small wins that feel ordinary at the time but become meaningful later. The day your open source project got its first external pull request. The evening you finally got CI passing after two days of flaky tests. The weekend you rewrote the API layer and it actually worked on the first deploy. These moments disappear from memory fast, but they are exactly the moments you want to look back on.
And if you want to, you can share it. deariary lets you publish individual diary entries with a public link. Some developers use this as a low-effort dev log for their projects: share the link on your README, on social media, or in a Discord server, and people can follow what you are building day by day. No blog to maintain, no writing to do. Just connect GitHub and your dev log writes itself.
What surprised us
We have been running deariary with GitHub connected since the earliest prototype. A few things surprised us along the way.
Patterns become visible. After a month of entries, you start to see rhythms in your work. Which days you do deep coding. Which days are review-heavy. These patterns are hard to spot from the contribution graph but obvious when you read your diary back.
Small contributions get recorded. A single thoughtful review comment on a colleague’s PR barely registers in your memory. On the contribution graph, it is the same tiny square as everything else. But the diary notes what you said and why. Over time, these small acts of collaboration add up to a record of how you actually spend your time, not just what you ship.
Multiple repos become one story. This was the biggest surprise. We expected the diary to list activity repo by repo. Instead, it weaves commits, reviews, and issues from different repositories into a coherent narrative about what you were working on that day. The unit is the topic, not the repository.
GitHub’s contribution graph is a good answer to “did I work today?” deariary answers a different question: “what did I actually do?” If you have ever scrolled back through your green squares and wished you could remember the details behind them, that is exactly what this integration is for.
