一個我認可的 Tag Release 發布流程（帶 CHANGELOG）#
這篇文章只是個個人工程記錄，目的是把版本發布這件事流程化、固定化，避免每次發布都臨時發揮。
核心原則只有一句話：
發布相關的所有改動必須在一個 Release PR 中完成，
Tag 和 Release 只能發生在 PR 合併之後。
1. 創建 release 分支#
git checkout -b release/v0.1.0
每次發布都從獨立的 release 分支開始。
2. 先更新 CHANGELOG.md#
在 CHANGELOG.md 中新增一個版本區塊，整理本次發布的所有變更。
## [0.1.0] - YYYY-MM-DD
### Added
- ...
### Fixed
- ...
### Changed
- ...
CHANGELOG 是發布內容的唯一權威來源。
3. 更新版本號#
修改 package.json 中的版本號（必要時同步 lockfile）。
{
"version": "0.1.0"
}
此階段 不創建 tag。
4. 一次性提交所有發布準備#
git add CHANGELOG.md package.json package-lock.json
git commit -m "chore(release): prepare v0.1.0"
版本號和 CHANGELOG 必須同時提交，不能拆開。
5. 創建 Release PR#
git push -u origin release/v0.1.0
gh pr create \
--title "chore(release): v0.1.0" \
--body "Release preparation for v0.1.0"
Release PR 中只包含發布相關內容：
- CHANGELOG 更新
- 版本號更新
- CI 校驗結果
6. 合併 Release PR#
Review 完成後，將 Release PR 合併到 main。
gh pr merge --merge
在此之前不允許打 tag。
7. 在 main 上創建 tag#
git checkout main
git pull origin main
git tag -a v0.1.0 -m "Release v0.1.0"
git push origin v0.1.0
Tag 指向的是已經被 review 和合併的最終狀態。
8. 從 CHANGELOG 生成 GitHub Release#
發布 GitHub Release 時，直接使用 CHANGELOG 對應版本的內容。
gh release create v0.1.0 \
--title "v0.1.0" \
--notes-file <(extract_changelog_section v0.1.0)
不手寫 Release Notes，避免與 CHANGELOG 不一致。
結語#
這個流程並不追求 “最快” 或 “最自動化”。
它的目標只有一個：
讓發布這件事變成一套可重複、可回溯、不容易出錯的固定動作。