WORKFLOW GUIDE

How to write release notes from Git commits

Use this six-step workflow to turn Git commit summaries into accurate customer-facing release notes without exposing implementation noise.

Select customer-visible commits
Start with shipped features, fixes, workflow changes, and verified performance updates that affect customers. Leave out test maintenance, dependency housekeeping, and internal refactors unless customers need to act.
Remove repository syntax
Strip commit hashes, issue and pull-request ids, branch names, conventional prefixes, and merge bookkeeping. Keep the descriptive words that explain the shipped behavior.
Group changes by meaning
Separate improvements from fixes, then keep maintenance or documentation details in notes only when they matter to the release audience. Do not let the commit type override what the description actually says.
Translate implementation into behavior
Replace file, function, service, and ticket language with the product area customers recognize and what is now possible, clearer, or more dependable. Preserve specific technical terms when customers use them.
Verify every added detail
Use dates, percentages, rollout scope, migration actions, and security outcomes only when the source material confirms them. Keep uncertain context out of the draft instead of filling gaps with plausible claims.
Generate, edit, and compare
Paste the selected summaries into the browser-local generator, edit the result against the shipped changes, remove empty sections, and confirm every final sentence maps back to verified input.

Start with the commits that changed customer behavior.

Paste selected commit or pull-request summaries and edit the browser-local draft before publishing.