How to generate a changelog from git commits

A changelog entry covers the commits between the previous release and this one. In git, A..B means commits reachable from B but not from A, so v1.3.0..HEAD is everything since v1.3.0, and v1.3.0..v1.4.0 is exactly what went into 1.4.0.

To find the previous tag, git describe --tags --abbrev=0 “finds the most recent tag that is reachable from a commit” (HEAD by default). Without --tags it only considers annotated tags, and --abbrev=0 drops the commit-count suffix so you get just the tag name. It's the nearest tag in your history, not the highest version number, so if you release from more than one branch, pass the tag explicitly.

git tag -a v1.4.0 -m "v1.4.0"
git push origin v1.4.0

--pretty=format: takes placeholders, so you can print each commit as a changelog line. --no-merges skips merge commits; --oneline is a quick shorthand when you just want to look.

- feat(parser): add parseStream() for large inputs (3f2c1ab)
- fix: handle Windows (CRLF) line endings (9d04e7c)
- refactor(parser): split the tokenizer (b81a6f0)
- chore(deps): bump test runner (2c7d9e4)

If you merge pull requests with merge commits, --first-parent follows only the first parent at each merge, so you see one merge commit per pull request on your main branch instead of every commit inside it. If you squash-merge, each pull request is already one commit, and its title is the subject.

git shortlog groups commits by author. -s prints only the commit count per person, -n sorts by that count, and --no-merges leaves merges out. Use it for a “Thanks to…” line in the release notes; the commit history already records who did what, so keep the credit brief.

Pull request titles are usually better raw material than individual commits. GitHub's generated release notes “include a list of merged pull requests, a list of contributors to the release, and a link to a full changelog”, grouped by the labels you set in .github/release.yml; Keep a Changelog vs GitHub Releases has a ready-made config.

• gh release create v1.4.0 --generate-notes creates the release with generated notes; --notes-start-tag v1.3.0 sets where they start.
• The REST endpoint POST /repos/{owner}/{repo}/releases/generate-notes returns the text without creating anything: “The generated release notes are not saved anywhere.” Useful for pasting into CHANGELOG.md.

If your commits follow Conventional Commits, a generator can sort them for you on every release. git-cliff writes a CHANGELOG.md from your history (git cliff -o CHANGELOG.md, or git cliff --unreleased for what's new since the last tag), and semantic-release, release-please and Changesets go further, choosing the version and creating the release. semantic-release vs release-please vs Changesets compares them. If you only want each GitHub release filled in, the free LogPulse GitHub Action sorts the commits since the last tag on every release, and uses your CHANGELOG.md section instead once you keep one. It's one workflow step, uses: kalmwerk/release-notes-action@v1 (on GitHub).

Keep a Changelog is blunt about raw logs: “Do not use a list of commits as a changelog. It is full of noise: merge commits, unclear messages, internal changes.” Before you publish the draft:

1. Sort each line into Added, Changed, Deprecated, Removed, Fixed or Security, under a ## [1.4.0] - YYYY-MM-DD heading. The CHANGELOG.md format guide has the full layout.
2. Delete internal changes: refactors, test and CI changes, dependency bumps nobody notices.
3. Merge the five commits that built one feature into one line, and rewrite it around what users see.
4. Mark breaking changes and add a migration step to each; see how to document breaking changes.
5. Add the compare link for the new version at the bottom of the file.