私が認める Tag Release 発行プロセス（CHANGELOG 付き）#
この記事は単なる個人的なプロジェクト記録であり、バージョンのリリースをプロセス化し、固定化することを目的としており、毎回のリリースで即興で行うことを避けます。
核心原則は一言です：
リリースに関連するすべての変更は、1 つの Release PR 内で完了しなければならず、
Tag と Release は PR がマージされた後にのみ行われる。
1. リリースブランチの作成#
git checkout -b release/v0.1.0
毎回のリリースは独立したリリースブランチから始まります。
2. まず CHANGELOG.md を更新#
CHANGELOG.md に新しいバージョンブロックを追加し、今回のリリースのすべての変更を整理します。
## [0.1.0] - YYYY-MM-DD
### 追加
- ...
### 修正
- ...
### 変更
- ...
CHANGELOG はリリース内容の唯一の権威ある情報源です。
3. バージョン番号の更新#
package.json のバージョン番号を変更します（必要に応じて lockfile を同期します）。
{
"version": "0.1.0"
}
この段階では タグを作成しません。
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 のマージ#
レビューが完了したら、Release PR を main にマージします。
gh pr merge --merge
この前にタグを打つことは許可されていません。
7. main でタグを作成#
git checkout main
git pull origin main
git tag -a v0.1.0 -m "Release v0.1.0"
git push origin v0.1.0
タグはレビューされ、マージされた最終状態を指します。
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 と不一致になることを避けます。
結語#
このプロセスは「最速」や「最も自動化されたもの」を追求しているわけではありません。
その目標はただ一つです：
リリースを繰り返し可能で、追跡可能で、間違えにくい固定動作にすること。