TLDR: If you want to remember what you shipped, you have four real options: scroll your git log, lean on GitHub's Insights tab, write things down manually, or run an automated digest tool. Git log is free but unreadable at scale. GitHub shows shape without substance. Manual journals work if you actually keep them. Automated digests handle the volume but cost a tiny amount per run. Pick by how much friction you tolerate.
Tracking what you shipped used to be a low-stakes problem. You wrote ten commits a day, the messages were yours, and you remembered the work because you typed it. That is not the world most developers live in anymore.
With AI coding tools, the same person can land fifty commits in an afternoon. The volume is bigger. The mental ownership is smaller. And by Friday you are looking at your own git history wondering what half of it does. (I wrote about why this happens in The Hidden Cost of Vibe Coding.)
So how do you keep up? Below are the four options that actually work, in order from zero-cost to most-automated.
Option 1: Read your git log
The cheapest option is the one already on your machine. Run git log --since="1 week ago" --oneline and you get a flat list of every commit from the past seven days, one per line. Add --stat if you want file change counts. Add -p if you want the actual diffs.
The good case: it costs nothing, it lives next to your code, and you can pipe it anywhere.
The bad case: at fifty commits a day with messages like fix, wip, and update, the log is illegible. You can scan it. You cannot understand it.
Use this when you have ten or fewer commits in the window and the messages are real.
Option 2: GitHub Insights
Every GitHub repo has an Insights tab. It shows commit frequency, code frequency, the contribution graph, and a pull-request summary. It is the easiest way to see the shape of your activity over time.
What Insights does well: at a glance, you can tell a busy week from a slow one. The green-square contribution graph is good for streaks. The pull-request list shows what crossed the finish line.
What Insights does badly: it shows counts. Counts are not summaries. Insights will tell you that you made 73 commits last week. It will not tell you what those commits did. If you want narrative, you have to read the diffs yourself.
Use this when you want a sense of pace, not detail.
Option 3: A developer journal
The classic answer is to write things down. End of day, jot what you worked on. Some people use a plain text file. Others use Obsidian, Notion, or a daily-notes plugin.
Journals capture the one thing automated tools miss: intent. You can record why you did something, not just what changed. That context compounds over months.
The catch is that journals only work if you actually keep them. The first two weeks are easy. The third week you forget once. The fourth week you stop. I have started and abandoned more dev journals than I can count, and I run a daily-digest company.
Use this if you genuinely have the discipline. Most people do not, which is fine.
Option 4: An automated digest
The newest option is to read what your repo did and turn it into a daily summary automatically. AskScout is one of these. So is anything you build yourself by piping git diffs into a ChatGPT or Claude prompt.
What you get is a written digest with sections: what shipped, what changed, what kept getting reworked, and where you left off. The output is short enough to read in 10 seconds. The data is grounded in your actual commits, not your memory.
What you give up is some control. The summary is the model's read of your diffs, not yours. If the model misreads a commit, the digest reflects that. You also pay a tiny LLM cost per run if you bring your own key (around $0.001 to $0.003 per digest at default models). The hosted web app is free.
Use this when the volume is too high for the other options. For most AI-assisted developers, that is most days.
How to pick
If your week is small and your messages are good, git log is fine. Stop reading.
If you only need a sense of pace, the GitHub contribution graph is enough.
If you have the discipline to write daily and you care about intent, keep a journal. Just be honest about whether you will actually do it for more than two weeks.
If your week is fifty commits a day with messy messages, the only option that scales is automation. Either build the prompt yourself or use a tool like AskScout. The point is that something is reading your repo for you, because at this volume you are not going to.
The honest answer is that most developers will end up using two of these together. A digest for the daily readout, plus a journal for the weeks that actually matter. The tools are not in conflict.
Frequently asked questions
What is the easiest way to track what I built this week?
The fastest path is git log --since="1 week ago" --oneline for a flat list of recent commits. If you want it summarized into plain English with sections for what shipped, what changed, and what you left off, an automated tool like AskScout reads the same data and writes a digest.
Does GitHub have a way to summarize my work?
GitHub's Insights tab shows commits, pull requests, and code frequency over time. It is good for shape and volume. It will not tell you what you actually built, since it shows counts and graphs rather than a written summary.
Should I keep a developer journal?
It works if you commit to writing daily. Most developers do not. The honest tradeoff is that journals capture intent and reasoning but require ongoing effort. Automated digests miss the intent but never go stale because they read your real git history.
Is there a free way to summarize my git activity?
Yes. The git CLI ships with git shortlog, git log --stat, and git log -p for a structured view at no cost. AskScout's CLI is also free open source software under MIT, with you bringing your own LLM API key (about $0.001 to $0.003 per digest).