1. 為什么需要規范的提交信息?
在團隊協作中，使用 Git、SVN 等這些版本管理工具。當我們提交代碼的時候，往往需要編寫提交信息（commit message）。
而提交信息的主要用途是：告訴這個項目的人，這次代碼提交里做了些什么。一般來說，建議小步提交，即按自己的任務步驟來的提交，每一小步都有對應的提交信息。這樣做的主要目的是：防止一次修改中，修改過多的文件，導致后期修改、維護、撤銷等等困難。
2. 參考 Angular 開源項目寫法
與我們日常工作稍有不同的是：工作中的 Release 計划一般都是事先安排好的，不需要一些 CHANGELOG 什么的。而開源項目需要有對應的 CHANGELOG.md ，則添加了什么功能、修改了什么等等。畢竟有很多東西是由社區來維護的。
Angular 團隊建議采用以下的形式：
<type>(<scope>): <subject> // 提交消息頭Message header <BLANK LINE> //空行 <body> // 提交具體內容 <BLANK LINE>//空行 <footer> // 額外內容
其中 Header 是必須的, body,footer 是可選的
例子在最后
2.1 提交消息頭 (commit message header)
<type> , 用於以下類型說明提交類型：
- build: 影響構建系統或外部依賴關系的更改（示例范圍：gulp，-
- broccoli，npm）
- ci: 更改我們的持續集成文件和腳本（e.g.: Travis，GitLab 等）
- docs: 僅文檔更改
- feat: 一個新功能
- fix: 修復錯誤
- perf: 改進性能的代碼更改
- refactor: 代碼更改，既不修復錯誤也不添加功能
- style: 不影響代碼含義的變化（空白，格式化，缺少分號等）
- test: 添加缺失測試或更正現有測試
- chore: 構建過程或輔助工具的變動
- release: 版本發布
- revert: 特殊情況，當前 commit 用於撤銷以前的 commit
<scope>, 說明 commit 影響的范圍
- 最好是指定提交更改位置 (結構的), 例如
$location,$browser,$compile,$rootScope,ngHref,ngClick,ngView等等 - 沒有合適的范圍可以使用
*
<subject>, 此次提交的簡短描述, 不應超過 50 個字符
- 以動詞開頭，使用第一人稱現在時，比如
change，而不是changed或changes - 第一個字母小寫
- 結尾不加句號（.）
// test類型實例 沒有指定scope
test: fix ts api guardian and public guard tests on windows (#30105)
2.2 提交消息具體內容 (commit message body)
<body> , 可選的, 此次提交詳細描述, 如果需要用到 body, 則應注意以下兩點
- 以動詞開頭，使用第一人稱現在時，比如
change，而不是changed或changes - 應該說明代碼變動的動機，以及與以前行為的對比。
// body實例
More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. Further paragraphs come after blank lines. - Bullet points are okay, too - Use a hanging indent
2.3 提交消息尾述 (commit message footer)
<footer> , 可選的, 此次提交描述的補充, 通常有兩種情況
- 不兼容的變動, 如果當前代碼與上一個版本不兼容，則 Footer 部分以
BREAKING CHANGE:開頭，后面是對變動的描述、以及變動理由和遷移方法。
BREAKING CHANGE: isolate scope bindings definition has >changed and the inject option for the directive controller injection was >removed. To migrate the code follow the example below: Before: scope: { myAttr: 'attribute', myBind: 'bind', myExpression: 'expression', myEval: 'evaluate', myAccessor: 'accessor' } After: scope: { myAttr: '@', myBind: '@', myExpression: '&', // myEval - usually not useful, but in cases where the >expression is assignable, you can use '=' myAccessor: '=' // in directive's template change >myAccessor() to myAccessor }
- 關閉 Issue, 需要關閉一個或多個某個 issue
Closes #123, #456, #789
3. Git 獲取提交消息格式化輸出
//1. 獲取提交列表message header
git log <last tag> HEAD --pretty=format:%s // 2. 過濾 類型 type git log <last release> HEAD --grep feature // 3. 跳過一些無關緊要的提交 git bisect skip $(git rev-list --grep irrelevant <good place> HEAD)
4. 與此同時還有一個名為 Conventional Commits 的規范，建議采用相似的形式。
5. 下面是一些提交例子
5.1 revert && refactor
revert: refactor(ivy): remove styling state storage and introduce dir…
…ect style writing (#32259) This reverts commit 15aeab1.
5.2 docs && footer
docs: move renderer2 deprecation guide into own file (#32626)
PR Close #32626
5.3 release
release: cut the v9.0.0-next.6 release
5.4 ci
ci: pin docker images by ID for hermeticity (#32602)
Previously, the docker images used on CI where specified by a tag (`10.16` and `10.16-browsers`). Since tags are not immutable, this only pins specific characteristics of the environment (e.g. the OS type and the Node.js version), but not others. Especially when using a tag that does not specify the patch version (e.g. `10.16` instead of `10.16.0`), it is inevitable that the image will change at some point, potentially leading to unrelated failures due to changes in the environment. One source of such failures can be the Chrome version used in tests. Since we install a specific ChromeDriver version (that is only compatible with specific Chrome version ranges), unexpectedly updating to a newer Chrome version may break the tests if the new version falls outside the range of supported version for our pinned ChromeDriver. Using a tag that specifies the patch version (e.g. `10.16.0`) or even the OS version (e.g. `10.16.0-buster`) is safer (i.e. has a lower probability of introducing the kind of breakages described above), but is still not fully hermetic. This commit prevents such breakages by pinning the docker images by ID. Image IDs are based on the image's digest (SHA256) and are thus immutable, ensuring that all CI jobs will be running on the exact same image. See [here][1] for more info on pre-built CircleCI docker images and more specifically [pinning images by ID][2]. [1]: https://circleci.com/docs/2.0/circleci-images [2]: https://circleci.com/docs/2.0/circleci-images#using-a-docker-image-id-to-pin-an-image-to-a-fixed-version PR Close #32602
5.5 pref
perf(ivy): check for animation synthetic props in dev mode only ([#32578](https://github.com/angular/angular/pull/32578))
5.6 fix
fix(ngcc): only back up the original `prepublishOnly` script and not …
…the overwritten one (#32427) In order to prevent `ngcc`'d packages (e.g. libraries) from getting accidentally published, `ngcc` overwrites the `prepublishOnly` npm script to log a warning and exit with an error. In case we want to restore the original script (e.g. "undo" `ngcc` processing), we keep a backup of the original `prepublishOnly` script. Previously, running `ngcc` a second time (e.g. for a different format) would create a backup of the overwritten `prepublishOnly` script (if there was originally no `prepublishOnly` script). As a result, if we ever tried to "undo" `ngcc` processing and restore the original `prepublishOnly` script, the error-throwing script would be restored instead. This commit fixes it by ensuring that we only back up a `prepublishOnly` script, iff it is not the one we created ourselves (i.e. the error-throwing one). PR Close #32427
5.7 等等 具體參考 anuglar 開源項目