修訂版本訊息指南
修訂訊息
清除修訂訊息可讓提取要求更方便查看,而版本資訊產生也較容易產生。Blockly 專案使用傳統修訂版本來協助解決此問題。
每個修訂版本都應採用以下格式:
<type>: <description>
[optional body]
[optional footer(s)]
請注意,核心 Blockly 存放區具有修訂版本 Lint,可協助您強制執行這項設定。如果提取要求有多個修訂版本,Linter 會檢查標題。如果它有一個修訂版本,便會檢查該修訂版本。建議您的個別修訂版本和提取要求標題都遵循上述規範。
類型
類型不得空白,也全為小寫。以下為可接受的類型的清單。
- 做家事
- 完成例行/自動化工作的修訂版本,例如昇級依附元件。
- 淘汰
- 針對淘汰功能的修訂版本。
- feat
- 針對為 Blockly 新增新功能的修訂版本。
- fix
- 修正 Blockly 中的錯誤/錯誤。
- 發行版本
- 針對與新版本相關的修訂版本。
破壞性變更
進行破壞性變更的修訂版本應在修訂版本類型之後附加 !
。破壞性變更可能會破壞開發人員在應用程式中使用 Blockly 的變更,因此必須執行額外工作。
例如:
fix!: return type of workspace.paste
破壞性變更可能包含上述任一有效類型。
說明
說明不可空白,且長度不得超過 256 個字元。
Body
內文是選用項目。如果提供,則與說明之間必須有空白行。不得超過 256 個半形字元。
請注意,通常建議將這類資訊放入提取要求說明,除了/而不是直接加入修訂版本。
頁尾是選用項目。如果提供,則其與主體之間應有一個空白行。且長度不可超過 256 個半形字元。
修正非傳統修訂版本
如果您在修改時未使用傳統修訂版本,視您擁有的修訂版本數量而定,有兩種方法可以修正訊息:
如果提取要求有多個修訂版本,請編輯提取要求標題以符合相關規定。提取要求合併時,系統會將其他修訂版本壓縮,讓標題成為修訂訊息。
如果提取要求只有一個修訂版本,請使用 git commit --amend
修訂修訂訊息,然後將變更強制推送至 Blockly 的分支。系統會自動更新與這個分支版本相關聯的所有公開提取要求。git push --force origin my-branch
.
除非另有註明,否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權,程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間:2023-12-01 (世界標準時間)。
[null,null,["上次更新時間:2023-12-01 (世界標準時間)。"],[[["Blockly utilizes conventional commits to standardize commit messages for improved readability and automation."],["Commit messages should follow the format `\u003ctype\u003e: \u003cdescription\u003e` with optional body and footer, using specific types like `feat`, `fix`, `chore`, etc."],["Breaking changes are indicated by appending `!` to the commit type and require careful consideration due to potential impact on developers."],["Commit messages are limited to 256 characters for descriptions and each line of the body/footer for conciseness."],["Non-conventional commit messages can be fixed by editing the pull request title (for multiple commits) or amending the commit message (for single commit)."]]],["Commit messages should adhere to the format `\u003ctype\u003e: \u003cdescription\u003e`, with optional body and footer. Valid types include `chore`, `deprecate`, `feat`, `fix`, and `release`; breaking changes append `!`. Descriptions must be under 256 characters. To rectify non-compliant messages, edit the pull request title for multiple commits or amend and force-push a single commit using `git commit --amend` and `git push --force`. A linter checks commit messages for each pull request.\n"]]