release-notes 是做什麼的？
將原始 Git 歷史轉換成人類會想閱讀的發行說明。
功能
- 比較兩個參考點（標籤、分支或
HEAD）之間的提交差異 - 依類型分組變更：功能、修復、重大變更、雜項
- 從 Conventional Commit 的
!標記和BREAKING CHANGE:頁尾檢測重大變更 - 起草重點摘要（使用者真正關心的 3-5 項變更）
- 輸出直接可用於 GitHub Release 的 Markdown
用法
# 即將發行版本的發行說明（上一個標籤 -> HEAD）
git log $(git describe --tags --abbrev=0)..HEAD --oneline
# 兩個標籤之間的發行說明
git log v1.2.0..v1.3.0 --pretty=format:'%h %s %b'
然後對助手說：「根據這些提交，為 v1.3.0 起草發行說明。」
或搭配 GitHub CLI 直接建立 Release 草稿：
# 建立標籤，然後從差異生成發行說明草稿
git tag v1.3.0 && git push origin v1.3.0
gh release create v1.3.0 --generate-notes --draft
# 然後使用這個技能優化生成的發行說明
流程
1. 收集提交記錄
git log <prev-tag>..<new-tag> --pretty=format:'%h|%s|%b|%an' --no-merges
如果儲存庫使用合併流程，則應另外包含合併提交 — 合併標題通常比單個提交更能總結 PR 的內容。
2. 分類每個提交
| 前綴 / 信號 | 分類 |
|---|---|
feat, feat! | 功能 |
fix | 錯誤修復 |
! 或 BREAKING CHANGE: | ⚠️ 重大變更（也會出現在自己的章節） |
perf | 效能改善 |
docs, chore, ci, refactor, test | 歸類於「其他變更」或省略 |
沒有 Conventional Commit 前綴的提交：根據訊息內容分類。如果不確定，與其無聲無息地丟棄，不如放進「其他變更」。
3. 起草重點摘要
選出對軟體使用者最重要的 3-5 項變更：
- 使用者會注意到的全新功能
- 使用者必須因應的重大變更
- 廣泛回報的錯誤修復
每一項用一句簡單的句子描述。不使用行銷形容詞。
4. 撰寫發行說明
## v1.3.0
**重點**
- ...
- ...
### ⚠️ 重大變更
- ...
### 功能
- ...
### 錯誤修復
- ...
### 其他變更
- ...
**完整變更記錄：** <prev-tag>...<new-tag>
5. 發布前的合理性檢查
- 每個重大變更都要出現在 ⚠️ 章節，並附上遷移提示
- 僅限內部使用的雜項不能當作面向使用者的功能呈現
- 如果儲存庫慣例有列出貢獻者，請給予貢獻者應有的署名
- 版本號必須與標籤一致
慣例
- 如果儲存庫已有既定的發行說明風格，請遵循該風格 — 一致性比任何範本都重要。
- 如果儲存庫使用
gh release --generate-notes，請以它的輸出作為起始草稿並進行優化：它能正確列出清單，但重點摘要常常不對。 - 絕不要編造提交範圍中不存在的變更。範圍不明確時，詢問要比較哪些參考點，不要自行猜測。