一个我认可的 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 不一致。
结语#
这个流程并不追求 “最快” 或 “最自动化”。
它的目标只有一个：
让发布这件事变成一套可重复、可回溯、不容易出错的固定动作。