規(guī)范的作用

大多數(shù)情況下，看提交歷史的人跟提交代碼的人都不是同一個(gè)人，當(dāng)別人閱讀你的提交歷史時(shí)，他很可能是不知道具體代碼細(xì)節(jié)的，你如何在最短的時(shí)間內(nèi)讓他一眼知道每次提交的意義：

• 每次提交影響的具體范圍？
• 這個(gè)bug在哪次提交中被修復(fù)了？
• 這個(gè)新功能是在哪次提交中增加的？
• 修改是否向下兼容？
• 是否回滾了代碼？
• 是否只是修改了文檔、調(diào)整了代碼格式？
• 是否修改了測(cè)試、是否進(jìn)行了重構(gòu)？
• 是否對(duì)代碼進(jìn)行了性能優(yōu)化？

這些都是提交規(guī)范的作用。

代碼復(fù)查/審查

良好的Git提交日志非常重要，最明顯的一點(diǎn)是，它讓整個(gè)Git提交歷史的閱讀變得非常輕松：

AngularJS commits

一眼看上去，就知道每個(gè)提交是做了什么，是加了新功能，還是修改了bug，是維護(hù)了文檔，還是調(diào)整了單元測(cè)試，都一目了然。

生成CHANGELOG

而且規(guī)范的Git提交歷史，還可以直接生成項(xiàng)目發(fā)版的CHANGELOG（semantic-release）：

AngularJS CHANGELOG

AngularJS的開發(fā)指南中已經(jīng)對(duì)Git的提交日志做了明確規(guī)范，這種規(guī)范幾乎適用于所有項(xiàng)目，本文搬運(yùn)過來，粗糙翻譯，與君共享。

規(guī)范細(xì)則

對(duì)于Git的提交日志，我們有非常明確而詳細(xì)的提交規(guī)范。這將有助于我們?cè)诓榭错?xiàng)目歷史時(shí)，更容易明確每一次提交的內(nèi)容。另一方面，我們還直接使用了Git提交日志來生成AngularJS的變更日志。

Git的提交日志可以通過常用的Git工作流或向?qū)Чぞ?Commitizen)來生成。如果你選擇使用Commitizen，那只需要在Git暫存修改后，執(zhí)行“yarn run commit”命令即可。

提交消息格式

每個(gè)提交消息都由一個(gè)標(biāo)題、一個(gè)正文和一個(gè)頁腳組成。而標(biāo)題又具有特殊格式，包括修改類型、影響范圍和內(nèi)容主題：

修改類型(影響范圍): 標(biāo)題 <--空行--> [正文] <--空行--> [頁腳]

標(biāo)題是強(qiáng)制性的，但標(biāo)題的范圍是可選的。

提交消息的任何一行都不能超過100個(gè)字符！這是為了讓消息在GitHub以及各種Git工具中都更容易閱讀。

修改類型

每個(gè)類型值都表示了不同的含義，類型值必須是以下的其中一個(gè)：

• feat：提交新功能
• fix：修復(fù)了bug
• docs：只修改了文檔
• style：調(diào)整代碼格式，未修改代碼邏輯（比如修改空格、格式化、缺少分號(hào)等）
• refactor：代碼重構(gòu)，既沒修復(fù)bug也沒有添加新功能
• perf：性能優(yōu)化，提高性能的代碼更改
• test：添加或修改代碼測(cè)試
• chore：對(duì)構(gòu)建流程或輔助工具和依賴庫（如文檔生成等）的更改

代碼回滾

代碼回滾比較特殊，如果本次提交是為了恢復(fù)到之前的某個(gè)提交，那提交消息應(yīng)該以“revert:”開頭，后跟要恢復(fù)到的那個(gè)提交的標(biāo)題。然后在消息正文中，應(yīng)該寫上“This reverts commit <hash>”，其中“<hash>”是要還原的那個(gè)提交的SHA值。

影響范圍

范圍不是固定值，它可以是你提交代碼實(shí)際影響到的任何內(nèi)容。例如$location、$browser、$compile、$rootScope、ngHref、ngClick、ngView等，唯一需要注意的是它必須足夠簡(jiǎn)短。

當(dāng)修改影響多個(gè)范圍時(shí)，也可以使用“*”。

標(biāo)題

標(biāo)題是對(duì)變更的簡(jiǎn)明描述：

• 使用祈使句，現(xiàn)在時(shí)態(tài)：是“change”不是“changed”也不是“changes”
• 不要大寫首字母
• 結(jié)尾不要使用句號(hào)

正文

正文是對(duì)標(biāo)題的補(bǔ)充，但它不是必須的。和標(biāo)題一樣，它也要求使用祈使句且現(xiàn)在時(shí)態(tài)，正文應(yīng)該包含更詳細(xì)的信息，如代碼修改的動(dòng)機(jī)，與修改前的代碼對(duì)比等。

頁腳

任何Breaking Changes（破壞性變更，不向下兼容）都應(yīng)該在頁腳中進(jìn)行說明，它經(jīng)常也用來引用本次提交解決的GitHub Issue。

Breaking Changes應(yīng)該以“BREAKING CHANGE:”開頭，然后緊跟一個(gè)空格或兩個(gè)換行符，其他要求與前面一致。

最后說一句

人生苦短，請(qǐng)遵守規(guī)范。

參考鏈接

https://github.com/angular/angular.js/commits/master

https://github.com/angular/angular.js/blob/master/CHANGELOG.md

https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines

https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#

總結(jié)

以上是生活随笔為你收集整理的from 下拉框多个值提交_Git提交规范的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。