How to Write Release Notes and Changelogs Faster on a Mac (Templates, Git Commands and Tools)

Release notes are the last thing standing between "it's merged" and "it's shipped," which is exactly why they get rushed. The result is a changelog that says Bug fixes and improvements and a support inbox full of people asking what changed.

Good release notes don't take long if the raw material is already organized. Here's the workflow I use to go from a list of commits to notes a user can skim in thirty seconds.

1. Decide who the notes are for

There are really two documents, and mixing them is why changelogs get unreadable:

• The changelog (CHANGELOG.md) is for developers and power users. It's complete, grouped by type, and lives in the repo.
• The release notes (GitHub release, App Store "What's New", a blog post or email) are for users. They lead with what someone will notice, skip internal refactors, and use plain words.

Write the changelog first. The release notes are a short, friendly edit of it.

2. Use a fixed structure

The Keep a Changelog format is the closest thing to a standard, and it's simple:

## [1.4.0] - 2026-10-24

### Added
- Export to CSV from the history view.

### Changed
- Settings now open in a separate window.

### Fixed
- Crash when the network drops during sync.

### Removed
- The legacy import option (deprecated since 1.2).

Keep an ## [Unreleased] section at the top and add a line to it in the same PR that makes the change. Then "writing the changelog" at release time is mostly renaming that heading.

3. Pull the raw list out of Git

If you didn't keep an Unreleased section, Git can give you a starting list. Everything since the last tag:

git log $(git describe --tags --abbrev=0)..HEAD --pretty=format:'- %s (%h)' --no-merges

If you use Conventional Commits (feat:, fix:, chore:), you can group by type straight away:

RANGE="$(git describe --tags --abbrev=0)..HEAD"
for t in feat fix perf; do
  echo "### $t"
  git log $RANGE --pretty=format:'- %s' --no-merges | grep "^- $t" | sed "s/^- $t[^:]*: /- /"
  echo
done

Pipe either one to pbcopy on a Mac and it's on your clipboard, ready to paste into your editor.

For merged pull requests instead of commits, the GitHub CLI works well:

gh pr list --state merged --base main --search "merged:>=2026-10-01" \
  --json number,title --jq '.[] | "- \(.title) (#\(.number))"'

4. Let GitHub draft it, then edit

GitHub can generate notes from merged PRs and their labels:

gh release create v1.4.0 --generate-notes --draft

Add a .github/release.yml to group PRs by label (enhancement, bug, and so on) and to exclude things like dependencies or chore. The draft is a first pass, not the finished notes, but it saves the copy-and-paste step.

5. Rewrite each line for the reader

This is the step that actually matters, and it's quick once the list exists. For every line, ask "what would a user notice?"

• fix: handle nil token in refresh flow becomes Fixed: you no longer get signed out after your Mac wakes from sleep.
• feat: add csv exporter becomes Added: export your history to CSV from File > Export.
• refactor: split SyncManager gets cut from the user-facing notes entirely.

Rules of thumb: start with a verb or the visible result, name the place in the UI, and delete anything a user can't see. Put the one change most people will care about first, even if it was the smallest diff.

6. Tools that make the writing part faster on a Mac

The Git side is scripted. The writing side is where these help:

• A Markdown editor with live preview. Anything that renders headings and code blocks as you type (Typora, iA Writer, or VS Code's built-in preview with Cmd+K V) makes it easy to see whether the notes skim well.
• Text snippets. Store your changelog skeleton (the four headings above) as a snippet in Raycast, Espanso or macOS's own Text Replacements (System Settings > Keyboard > Text Replacements) so a new release section is one keyword away.
• DraftKey ($4.99 lifetime, getdraftkey.com). An on-device AI writing assistant that works in any Mac text field, including the GitHub release box and App Store Connect's "What's New" field. Tab completes the sentence you've started, and selecting a terse commit-style line lets you ask for a clearer or shorter rewrite, which is exactly the step 5 edit. The model runs locally, so unreleased feature names don't go to a cloud service. It needs an Apple Silicon Mac on macOS 14 or later and has no free trial. Disclosure: I built DraftKey.

7. A checklist before you hit Publish

• Version number and date match the tag.
• The most noticeable change is first.
• Breaking changes and removed features are called out explicitly, with what to do instead.
• Every line describes something a user can see or do.
• Links to docs or issues for anything that needs more than one sentence.
• The App Store / website / email version is a shortened copy, not a separate rewrite.

The short version

Keep an Unreleased section, pull the rest from git log or gh, let --generate-notes draft it, then spend five minutes rewriting each line from the user's point of view. The scripting gets you a list; the rewrite is what makes people read it.

How does your team handle release notes? I'd like to hear what's worked in the comments.