Generating Changelogs from Git History

A changelog written by hand tends to get skipped near release time. Since every change is already recorded in git, you can hand that history to Claude and get a readable summary in seconds.

Pipe the log in

Headless mode reads from a pipe, so send it the commits since your last tag.

git log v1.2.0..HEAD --pretty=format:"%s" | \
  claude -p "Turn these commit subjects into a changelog grouped by Added, Changed, and Fixed. Use plain bullet points."

Claude reads the raw subjects and organizes them into sections a reader can scan, dropping the noise like merge commits and formatting-only tweaks.

Give it more to work with

Commit subjects alone are terse. For a richer summary, include the body of each commit so Claude understands the reasoning, not just the headline.

git log v1.2.0..HEAD --pretty=format:"%s%n%b%n---" | \
  claude -p "Summarize these changes into release notes for end users. Focus on what they will notice."

Notice the shift in audience: the same history can become a terse developer changelog or a friendly user-facing note, depending on what you ask for.

Write it to a file

Headless output goes to standard output, so append it straight into your changelog file and review the result before committing.

git log v1.2.0..HEAD --pretty=format:"%s" | \
  claude -p "Write a Markdown changelog section for this release." >> CHANGELOG.md

Good commits make good changelogs

The quality of the summary tracks the quality of your history. Small, well-described commits give Claude clear material to group. Sprawling commits titled "wip" give it guesswork. This is one more reason the commit habits from earlier in the series pay off later.