Three times a month someone asks the same question in a different costume. It's the Monday standup, the Friday update to your manager, or the quarterly review where you're supposed to list what you shipped.

You open git log and find fix, updates, wip, and one commit that just says final. So you reconstruct the week from memory, Slack scrollback and calendar entries — and still forget the one thing that took two days.

The information isn't missing. It was just never written down in a form you can read later.

1. The Raw Material Is a By-Product

Every time you run gitaiflow, it saves a timestamped JSON summary of that run under change-summary/<YYYY>/<MM>/<DD>/json/. You don't do anything extra; it's a side effect of the summary you were already generating.

After a week of normal work, that folder is a log of what you changed, written at the time you changed it, in plain language.

2. Turn a Date Range Into a Readable Entry

gitaiflow --changelog --since "1 week ago" --path .

--since takes an exact date like 2026/10/01 or a relative one like 3 days ago or 2 weeks ago. --until sets the end of the range, and defaults to now for relative dates. A range that starts before the repo's first commit, or in the future, is rejected up front.

gitaiflow reads the summaries in that range and sorts each bullet into a section: Breaking Changes, Security, Features, Fixes, and so on. It also recognizes the type of project — Python, Go, JavaScript or TypeScript — and adds sections that make sense there, such as database migrations or dependencies.

The sorting is rule-based first: keywords, file paths and commit types decide where a bullet goes, which is free and works offline. Only bullets that no rule claims are sent to the AI, and only when there are enough of them to be worth grouping.

One thing to know before you run it: the entry is written into CHANGELOG.md, under a heading for your project's current version (read from pyproject.toml, package.json, composer.json, Cargo.toml or a VERSION file). Your other release entries are left untouched. Check it with git diff CHANGELOG.md, and discard the change if you only wanted to read the result.

3. Why It Doesn't Double-Count

A week of runs produces overlapping summaries — you summarized the same files on Tuesday and again on Thursday. Turning all of them into bullets would list the same work twice. A few rules prevent that:

• Newest wins. When several runs touched the same files, the newest summary is kept and older overlapping ones are dropped.
• Wrong-branch summaries are filtered out. Summaries live in your working directory, not in git, so they follow you when you switch branches. gitaiflow only keeps a summary if most of its files still differ from the base branch in your current checkout.
• Committed work with no summary is filled in from git. Commits unique to your branch are added only if their title isn't already covered by a summary.
• No summaries at all? It falls back to the git log of the base branch instead.

Want the Full Picture?

This post covers the weekly-rollup use. The full changelog configuration, including how to customize sections per project, is in the gitaiflow documentation ↗.

What I'd Tell You If You're Building Something Similar

1. Capture while the context is fresh, assemble later. Writing a small record at the moment of work is far cheaper than reconstructing it a week afterwards.
2. Don't ask a model to do what a rule can do for free. Sorting by file path and commit type is faster, cheaper and more predictable than asking an AI to classify everything.
3. When several records describe the same work, decide which one wins before you merge them. Without that rule, every overlap becomes a duplicate line.