一次规范的 Tag Release 发布流程

一个我认可的 Tag Release 发布流程（带 CHANGELOG）

这篇文章只是一个个人工程记录，目的是把版本发布这件事流程化、固定化，避免每次发布都临时发挥。

核心原则只有一句话：

发布相关的所有改动必须在一个 Release PR 中完成，
Tag 和 Release 只能发生在 PR 合并之后。

1. 创建 release 分支

Copy
git checkout -b release/v0.1.0

每次发布都从独立的 release 分支开始。

2. 先更新 CHANGELOG.md

在 CHANGELOG.md 中新增一个版本区块，整理本次发布的所有变更。

Copy
## [0.1.0] - YYYY-MM-DD

### Added
- ...

### Fixed
- ...

### Changed
- ...

CHANGELOG 是发布内容的唯一权威来源。

3. 更新版本号

修改 package.json 中的版本号（必要时同步 lockfile）。

Copy
{
"version": "0.1.0"
}

此阶段 不创建 tag。

4. 一次性提交所有发布准备

Copy
git add CHANGELOG.md package.json package-lock.json
git commit -m "chore(release): prepare v0.1.0"

版本号和 CHANGELOG 必须同时提交，不能拆开。

5. 创建 Release PR

Copy
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。

Copy
gh pr merge --merge

在此之前不允许打 tag。

7. 在 main 上创建 tag

Copy
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 对应版本的内容。

Copy
gh release create v0.1.0 \
--title "v0.1.0" \
--notes-file <(extract_changelog_section v0.1.0)

不手写 Release Notes，避免与 CHANGELOG 不一致。

结语

这个流程并不追求 “最快” 或 “最自动化”。

它的目标只有一个：
让发布这件事变成一套可重复、可回溯、不容易出错的固定动作。