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 官方產品。
