release please
v16.15.0
Release Please 自动生成 CHANGELOG、创建 GitHub 版本以及项目的版本更新。
它通过解析您的 git 历史记录、查找常规提交消息并创建发布 PR 来实现这一点。
它不处理向包管理器的发布或处理复杂的分支管理。
release-please 不是持续发布默认分支上的内容，而是维护发布 PR：
随着其他工作的合并，这些发布 PR 会保持最新。当您准备好标记某个版本时，只需合并该版本 PR 即可。挤压合并和合并提交都适用于发布 PR。
当Release PR合并时，release-please采取以下步骤：
更新您的变更日志文件（例如CHANGELOG.md ）以及其他语言特定文件（例如package.json ）。
用版本号标记提交
根据标签创建 GitHub Release
您可以通过 PR 本身的状态标签来判断 Release PR 处于其生命周期中的哪个位置：
autorelease: pending是Release PR合并前的初始状态
autorelease: tagged表示该Release PR已被合并，并且该release已在GitHub中被标记
autorelease: snapshot是快照版本碰撞的特殊状态
autorelease: published表示已经基于 Release PR 发布了 GitHub 版本（ release-please 不会自动添加此标签，但我们建议将其作为发布工具的约定）。
请发布假设您正在使用常规提交消息。
您应该记住的最重要的前缀是：
fix:代表错误修复，与 SemVer 补丁相关。
feat:代表一个新功能，并与 SemVer 次要相关。
feat!:或fix!: 、 refactor!:等，它们代表重大更改（由!指示）并将导致 SemVer 主要。
我们强烈建议您在合并拉取请求时使用压缩合并。线性 git 历史记录使以下操作变得更加容易：
关注历史记录 - 提交按合并日期排序，并且不会在拉取请求之间混合
查找并恢复错误 - git bisect有助于追踪哪个更改引入了错误
控制发布-请更改日志 - 当您合并 PR 时，您可能会提交在 PR 范围内有意义的消息，但在合并到主分支中时则没有意义。例如，您可能有feat: introduce feature A ，然后fix: some bugfix introduced in the first commit 。 fix提交实际上与发行说明无关，因为主分支中从未遇到过错误。
保持一个干净的主分支 - 如果您使用红/绿开发之类的东西（在提交 A 中创建失败的测试，然后在提交 B 中修复）并合并（或 rebase-merge），那么您的主分支中将会有时间点测试未通过的地方。
Release Please 允许您使用页脚在一次提交中表示多个更改：
壮举：将 v4 UUID 添加到加密货币中 这为库添加了对 v4 UUID 的支持。 修复（utils）：unicode 不再抛出异常 PiperOrigin-修订 ID：345559154 重大更改：编码方法不再抛出异常。 来源链接：googleapis/googleapis@5e0dcb2 feat(utils)：更新编码以支持 unicode PiperOrigin-修订 ID：345559182 来源链接：googleapis/googleapis@e5eef86
上面的提交消息将包含：
“将 v4 UUID 添加到加密”功能的条目。
修复“unicode 不再抛出异常”的条目，以及说明这是一项重大更改的注释。
功能“更新编码以支持 unicode”的条目。
当对主分支的提交在提交正文中包含Release-As: xxx （不区分大小写）时，Release Please 将为指定版本打开一个新的拉取请求。
空提交示例：
git commit --allow-empty -m "chore: release 2.0.0" -m "Release-As: 2.0.0"会产生以下提交消息：
杂务：发布 2.0.0 发布版本：2.0.0
如果您合并了拉取请求并想要修改用于生成该提交的发行说明的提交消息，您可以编辑合并的拉取请求的正文并添加如下部分：
BEGIN_COMMIT_OVERRIDE feat: add ability to override merged commit message fix: another message chore: a third message END_COMMIT_OVERRIDE
下次运行 Release Please 时，它将使用该覆盖部分作为提交消息，而不是合并的提交消息。
Release Please 在注意到默认分支包含自上次发布以来的“可发布单元”后创建一个发布拉取请求。可发布单元是对具有以下前缀之一的分支的提交：“feat”、“fix”和“deps”。 （“杂务”或“构建”提交不是可发布的单元。）
某些语言有其特定的可发布单元配置。例如，“docs”是 Java 和 Python 中可发布单元的前缀。
autorelease: pending或autorelease: triggered标签检查标有autorelease: pending或autorelease: triggered标签的现有拉取请求。由于 GitHub API 故障，可能在之前的版本中未正确删除标签，并且 Release Please 认为之前的版本仍处于待处理状态。如果您确定没有待发布的版本，请删除autorelease: pending或autorelease: triggered标签。
对于 GitHub 应用程序用户，如果存在标记为autorelease: pending的现有拉取请求，Release Please 不会创建新的拉取请求。要确认这种情况，请搜索带有标签的拉取请求。 （很可能是最新的发布拉取请求。）如果您发现带有标签的发布拉取请求，并且它不会发布（或已经发布），则删除autorelease: pending标签并重新运行 Release Please。
如果您认为 Release Please 在合并具有可发布单元的拉取请求后错过了创建发布 PR，请重新运行release-please 。如果您使用的是 GitHub 应用程序，请将release-please:force-run标签添加到合并的拉取请求中。如果您正在使用该操作，请查找失败的调用并重试工作流运行。 Release Please 将立即处理拉取请求以查找可发布的单元。
Release Please 自动发布以下版本的存储库：
| 释放类型 | 描述 |
|---|---|
bazel | 一个 Bazel 模块，带有 MODULE.bazel 和 CHANGELOG.md |
dart | 带有 pubspec.yaml 和 CHANGELOG.md 的存储库 |
elixir | 带有 mix.exs 和 CHANGELOG.md 的存储库 |
go | 带有 CHANGELOG.md 的存储库 |
helm | 带有 Chart.yaml 和 CHANGELOG.md 的存储库 |
java | 每次发布后生成快照版本的策略 |
krm-blueprint | 一个 kpt 包，包含 1 个或多个 KRM 文件和一个 CHANGELOG.md |
maven | Maven项目策略，每次发布后生成SNAPSHOT版本并自动更新pom.xml |
node | 一个 Node.js 存储库，带有 package.json 和 CHANGELOG.md |
expo | 基于 Expo 的 React Native 存储库，包含 package.json、app.json 和 CHANGELOG.md |
ocaml | 一个 OCaml 存储库，包含 1 个或多个 opam 或 esy 文件以及 CHANGELOG.md |
php | 带有composer.json和CHANGELOG.md的存储库 |
python | 一个 Python 存储库，包含 setup.py、setup.cfg、CHANGELOG.md 以及可选的 pyproject.toml 和 <project>/__init__.py |
ruby | 具有 version.rb 和 CHANGELOG.md 的存储库 |
rust | 一个 Rust 存储库，带有 Cargo.toml（作为板条箱或工作区，但请注意，工作区需要清单驱动的版本和“cargo-workspace”插件）和 CHANGELOG.md |
sfdx | 具有 sfdx-project.json 和 CHANGELOG.md 的存储库 |
simple | 具有 version.txt 和 CHANGELOG.md 的存储库 |
terraform-module | 一个 terraform 模块，其版本位于 README.md 和 CHANGELOG.md 中 |
您可以通过多种方式部署发布版本，请：
运行 Release Please 的最简单方法是作为 GitHub 操作。请参阅 googleapis/release-please-action 了解安装和配置说明。
请参阅运行release-please CLI 了解所有配置选项。
有一个 Probot 应用程序可用，它允许您将 Release Please 部署为 GitHub 应用程序。请参阅 github.com/googleapis/repo-automation-bots 了解安装和配置说明。
发布请查看自上次发布标签以来的提交。它可能能够也可能无法找到您以前的版本。加入存储库的最简单方法是引导清单配置。
Release Please 提供了多个配置选项来允许自定义您的发布过程。请参阅customizing.md 了解更多详细信息。
Release Please 还支持从同一存储库发布多个工件。更多信息请参见manifest-releaser.md。
我们的客户端库遵循 Node.js 发布时间表。库与 Node.js 所有当前的活动版本和维护版本兼容。
针对 Node.js 的某些生命周期结束版本的客户端库可用，并且可以通过 npm dist-tags 安装。 dist-tags 遵循命名约定legacy-(version) 。
尽最大努力支持旧版 Node.js 版本：
旧版本不会在持续集成中进行测试。
某些安全补丁可能无法向后移植。
依赖项不会保持最新，功能也不会向后移植。
legacy-8 ：从此 dist-tag 安装客户端库，以获取与 Node.js 8 兼容的版本。
该库遵循语义版本控制。
欢迎投稿！请参阅贡献指南。
有关库设计的更多信息，请参阅设计。
有关常见问题和帮助对配置进行故障排除的信息，请参阅故障排除。
阿帕奇2.0版
查看许可证
这不是 Google 官方产品。
