It's release day. You tag the release, then stare at 40 commits trying to remember what actually shipped. So you scroll through a raw log, copy-paste subject lines into a text file, squint at which ones are features and which are just chores, and miss the one breaking change buried at commit #27.
git-release-notes does that archaeology for you — in one command, offline, conventional-commit aware:
curl -O https://raw.githubusercontent.com/hahahahahahahahah6/git-release-notes/main/git_release_notes.py
chmod +x git_release_notes.py
./git_release_notes.py
## Breaking Changes
- drop legacy auth endpoints (9f2c41a)
## Features
- add login form (e4b7d21)
- dark mode toggle (7c0a55f)
## Fixes
- crash on empty input (a91be30)
## Other changes
- update readme (3d55f12)
- bump deps (6f0e8a4)
With no arguments it diffs from the most recent tag reachable from HEAD to HEAD (and if the range is empty only because you just tagged, it falls back to the previous tag instead). Conventional-commit types (feat, fix, docs, chore, refactor, perf, test, build, ci) get their own sections; ! markers and BREAKING CHANGE: footers go in Breaking Changes first. Everything else collapses into Other changes unless --verbose splits it out. --json for scripts, --title v1.4.0 for a header, and the markdown goes to stdout — pipe it to pbcopy or straight into your release page.
This is not a GitHub-Action release drafter. No API, no tokens, no CI workflow to wire up — it works on a plane, in a monorepo, on a bare server. One file, stdlib only, Python 3.9+. git is the only other thing it needs, and it's already there if you're releasing.
13/13 tests pass. MIT licensed.
Repo: https://github.com/hahahahahahahahah6/git-release-notes
How do you write your release notes today — by hand, by action, or not at all?
Top comments (0)