要触发 Google 的 release-please 工具自动生成发布，您的提交信息需要遵循 Conventional Commits 规范。以下是能触发自动发布的提交格式和示例：

参考: https://www.conventionalcommits.org/en/v1.0.0/

核心触发规则

release-please 会解析提交信息中的 类型（type） 和 破坏性变更标记（BREAKING CHANGE） 来决定版本号升级：

  1. feat → 触发 次版本号升级 (e.g., 1.0.0 → 1.1.0)
  2. fix → 触发 修订版本号升级 (e.g., 1.0.0 → 1.0.1)
  3. BREAKING CHANGE → 触发 主版本号升级 (e.g., 1.0.0 → 2.0.0)

有效提交格式示例

1. 功能提交（触发次版本升级）

feat: add user authentication API

或带作用域（scope）：

feat(auth): implement OAuth2 login

2. 修复提交（触发修订版本升级）

fix: resolve memory leak in data processing

或带作用域：

fix(parser): handle empty JSON input correctly

3. 破坏性变更（触发主版本升级）

方式一：在提交脚注中声明

feat: redesign permission system
BREAKING CHANGE: The `role` field is now required in user objects.

方式二：在提交标题中标记

feat(api)!: remove deprecated endpoint

注意：! 表示破坏性变更（等同于脚注中的 BREAKING CHANGE）

4. 其他类型提交（不触发版本升级）

以下类型不会触发版本升级，但会出现在变更日志中：

docs: update README installation guide
style: format code with Prettier
refactor: simplify payment module logic
test: add unit tests for checkout flow
chore: upgrade dependencies to latest versions

关键注意事项

  1. 破坏性变更必须显式声明：
    • 必须使用 BREAKING CHANGE: 开头的脚注（大小写敏感）
    • 或在提交标题类型后加 !（如 feat!: 或 fix!:）
  2. 提交信息结构： 
    <type>[optional scope]: <description>
[optional body]
[optional footer(s)]
    • 类型（type）必须用小写（如 feat/fix）
    • 作用域（scope）用括号包裹（如 (auth)）
    • 描述（description）用现在时态（如 add 而非 added）
  3. 多行提交示例： 
    feat(auth)!: switch to JWT tokens
The old cookie-based auth is deprecated. All clients must migrate
to the new JWT endpoint by v2.0.
BREAKING CHANGE: Removes support for cookie authentication.

无效提交示例（不会触发发布）

# 缺少类型前缀
Add new login feature
# 类型错误（非 feat/fix）
docs: fix typo in API docs  # 属于文档修复，不触发版本升级
# 破坏性变更未声明
feat: remove old API  # 没有 `!` 或 `BREAKING CHANGE` 脚注

如何验证提交格式？

  1. 使用工具检查： 
    npm install -g commitlint
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
commitlint --from HEAD~1  # 检查最近一次提交
  2. 在 CI/CD 中集成 commitlint 阻止不合规提交。

release-please 工作流程

  1. 检测提交：扫描分支中的 Conventional Commits
  2. 计算版本：
    • 有 feat → 次版本 +1
    • 有 fix → 修订版本 +1
    • 有 BREAKING CHANGE → 主版本 +1
  3. 生成文件：
    • 更新 package.json/Cargo.toml 中的版本号
    • 创建 CHANGELOG.md
    • 生成 GitHub Release 草稿

⚠️ 重要：release-please 默认处理 默认分支（如 main/master）的提交，确保您的功能分支已合并到默认分支。

最佳实践

  1. 团队规范：强制所有开发者使用 Conventional Commits
  2. 提交模板：在 .gitcommit-template 中预定义格式
  3. 自动化工具：
    • 使用 commitizen 交互式生成提交： 
      npm install -g commitizen
echo '{ "path": "cz-conventional-changelog" }' > .czrc
git cz  # 替代 git commit
    • 集成 husky + commitlint 在 Git hooks 中验证提交
      通过遵循以上规则，release-please 将自动根据您的提交历史生成版本号和发布说明！