How do I write a changelog from my git commits?

A git log is written for the people who made the change. A changelog is written for the people who use the project. Pasting one into the other gives you lines like "fix typo" and "wip", which tell a reader nothing.

The job is mostly sorting. Which commits would a user notice? Which belong together? Which are internal? An assistant can do that sort in a minute, as long as it is not allowed to make anything up. The rule that matters here: every line in the changelog must point back to a commit.

What you need

• The log for one release. Run git log --no-merges --format='%h %s%n%b---' v1.2.0..HEAD, using your own tag or range, and copy the output.
• Nothing else. You do not need to know the version number yet.

The prompt

Paste this into a new chat, then paste the log under it.

You write a changelog section for one release from the git log I paste below. Readers are people who use the project, not its maintainers. Every entry must trace to a commit; put the short hash in parentheses at the end of each line. Never invent a version number, date or breaking change. You see only commit messages, so do not describe behaviour beyond what a message says.

1. Decide for each commit whether it is user-facing. Keep new features, behaviour changes, noticeable bug fixes, removals and deprecations, security fixes and visible performance changes. Skip formatting, comment typos, CI, test-only changes and internal refactors (give one line at the end with their count and hashes).
2. Merge commits that belong together into one entry with all their hashes.
3. Write `## [VERSION] - DATE` (leave both as placeholders), then only the headings that have entries: Added, Changed, Fixed, Deprecated, Removed, Security. One line per entry in the reader's terms, for example "Fixed a crash when the config file is empty", not the commit's wording.
4. After the changelog list: vague commits (message does not say what changed) as [CHECK: hash "message"]; possible breaking changes only if a message says BREAKING or has "!" (otherwise say none were evident and that you saw only messages); skipped commits.
No marketing language.

Here is the git log:

[paste the log here]

How to check the result

Open the log next to the draft and follow the hashes. Each entry should have one or more hashes, and the message behind each hash should support the line. If a line says more than the commit message does, cut it back.

Then read the section the prompt calls Flags. Vague commits come back as a [CHECK: ...] line. These are the ones the assistant could not understand from the message alone, so look at the diff yourself and write the entry by hand.

Look at the skipped commits too. The prompt gives you a count and hashes. A commit that looks like a refactor sometimes changes behaviour, and you are the only one who knows.

The headings follow the Keep a Changelog convention: Added, Changed, Deprecated, Removed, Fixed and Security. The keepachangelog.com page explains each one, and its own advice is not to dump git logs into a changelog, which is the point of this exercise: https://keepachangelog.com/en/1.1.0/

Limits

• The assistant sees commit messages, not code. It cannot know what a commit like "update deps" did to your users.
• It will not tell you the version number or the date. Both are left as placeholders on purpose.
• Possible breaking changes are only flagged if a message says so. A breaking change in a commit that says nothing will be missed. Read the diffs of anything touching a public interface.
• Short logs work best. For a very large range, split it by month and merge the results yourself.

Browse all skills in the catalog

Want this as a ready-made skill? Changelog from Commits (Free) does it in your own assistant.