自古至今，無規矩不成方圓。
Git提交也有其規范，業內做的比較好的，比較具有參考價值的就是Angular的提交。
Angular提交規范:
<type>(<scope>): <subject> #header // 空一行 <body> // 空一行 <footer>
格式講解
Header
Header部分只有一行，包括三個字段：type（必需）、scope（可選）和subject（必需）。
總的來說，關鍵就是header這部分，至於<body>和<footer>可省略
例如:
feat:新增財務報表
type
用於說明本次commit的類別，只允許使用下面7個標識
feat：新功能（feature）fix：修補bugdocs：文檔（documentation）style： 格式（不影響代碼運行的變動）refactor：重構（即不是新增功能，也不是修改bug的代碼變動）test：增加測試chore：構建過程或輔助工具的變動
注意:如果type為feat和fix，則該 commit 將肯定出現在 Change log 之中。其他情況（docs、chore、style、refactor、test）由你決定，要不要放入 Change log，建議是不要。
scope
用於說明 commit 影響的范圍，比如數據層、控制層、視圖層等等，視項目不同而不同。
subject
是 commit 目的的簡短描述，不超過50個字符。
以動詞開頭，使用第一人稱現在時，比如change，而不是changed或changes 第一個字母小寫 結尾不加句號（.）
反面示例1:
不要像如下這樣提交，顯得可笑（反面示例，以示警戒）
上面就是一部門功能，按照angular這種提交規范，應該要這樣:
feat:完成部門管理功能
當然了，這樣提交信息是叫完成部門管理功能,肯定是要包含上述的什么分頁，新增，修改，刪除等等的。沒有必要這么寫一大堆羅里吧嗦的。
反面示例2:
這個提交信息讓人覺得太泛。你提交的信息是財務，財務有很多功能啊，比如財務報表，其中報表又分月報表和日報表，報表中還有支出報表和收入報表等等。
上述的提交缺點是信息不明確，太泛。
反面示例3:
刪除文件，同樣也是信息不明確，不過這個人犯的錯誤是實際刪除了一個Java類，當然了，Java類也是一個文件，不過這里讓人很疑惑，你到底刪除了幾個類啊或者是其他文件呢？你光就一個提交信息，說刪除文件，鬼知道你刪除了多少文件。
既然是刪除文件，你可以這樣提交信息:
del:刪除cn.test包下的Test.Java
這樣與上面對比，豈不是簡潔的多。
當然了，實際中，也不一定要采用Angular這種，但是你可以借鑒它的，然后自己那邊再根據實際情況變動。
提交規范在於以后維護方面是非常有利的，先不說遠的，近的話，使用Git時，合並代碼通常會有沖突，有些突發意外，比如另外的人不小心將你的代碼覆蓋了，而且這個功能已經是很久之前的了，那怎么辦呢？通常情況，本地有備份固然好，但是估計也沒有那個人會將自己每次提交，都本地保存一份，因為那樣顯得效率低下和根據項目的周期和需求，項目越來越大，這樣的話，本地備份的包也會越來越多。沒有人會選擇這種方式。最后的方式就是版本回退，當然了，前提是你提交信息必須簡潔明了，不然的話像上面的反面例子，鬼知道是哪個。
另外關於什么時候，提交，盡可能是完成一個新的功能或者是優化某個功能，解決某個bug等等就提交。但是這里有個前提就是，你本地必須測試沒有問題，否則那樣等於做無用工。
希望這篇文章能給大家帶來幫助。
本文轉載自：
關於Git提交規范
自古至今，無規矩不成方圓。
Git提交也有其規范，業內做的比較好的，比較具有參考價值的就是Angular的提交。
Angular提交規范:
<type>(<scope>): <subject> #header // 空一行 <body> // 空一行 <footer>
格式講解
Header
Header部分只有一行，包括三個字段：type（必需）、scope（可選）和subject（必需）。
總的來說，關鍵就是header這部分，至於<body>和<footer>可省略
例如:
feat:新增財務報表
type
用於說明本次commit的類別，只允許使用下面7個標識
feat：新功能（feature）fix：修補bugdocs：文檔（documentation）style： 格式（不影響代碼運行的變動）refactor：重構（即不是新增功能，也不是修改bug的代碼變動）test：增加測試chore：構建過程或輔助工具的變動
注意:如果type為feat和fix，則該 commit 將肯定出現在 Change log 之中。其他情況（docs、chore、style、refactor、test）由你決定，要不要放入 Change log，建議是不要。
scope
用於說明 commit 影響的范圍，比如數據層、控制層、視圖層等等，視項目不同而不同。
subject
是 commit 目的的簡短描述，不超過50個字符。
以動詞開頭，使用第一人稱現在時，比如change，而不是changed或changes 第一個字母小寫 結尾不加句號（.）
反面示例1:
不要像如下這樣提交，顯得可笑（反面示例，以示警戒）
上面就是一部門功能，按照angular這種提交規范，應該要這樣:
feat:完成部門管理功能
當然了，這樣提交信息是叫完成部門管理功能,肯定是要包含上述的什么分頁，新增，修改，刪除等等的。沒有必要這么寫一大堆羅里吧嗦的。
反面示例2:
這個提交信息讓人覺得太泛。你提交的信息是財務，財務有很多功能啊，比如財務報表，其中報表又分月報表和日報表，報表中還有支出報表和收入報表等等。
上述的提交缺點是信息不明確，太泛。
反面示例3:
刪除文件，同樣也是信息不明確，不過這個人犯的錯誤是實際刪除了一個Java類，當然了，Java類也是一個文件，不過這里讓人很疑惑，你到底刪除了幾個類啊或者是其他文件呢？你光就一個提交信息，說刪除文件，鬼知道你刪除了多少文件。
既然是刪除文件，你可以這樣提交信息:
del:刪除cn.test包下的Test.Java
這樣與上面對比，豈不是簡潔的多。
當然了，實際中，也不一定要采用Angular這種，但是你可以借鑒它的，然后自己那邊再根據實際情況變動。
提交規范在於以后維護方面是非常有利的，先不說遠的，近的話，使用Git時，合並代碼通常會有沖突，有些突發意外，比如另外的人不小心將你的代碼覆蓋了，而且這個功能已經是很久之前的了，那怎么辦呢？通常情況，本地有備份固然好，但是估計也沒有那個人會將自己每次提交，都本地保存一份，因為那樣顯得效率低下和根據項目的周期和需求，項目越來越大，這樣的話，本地備份的包也會越來越多。沒有人會選擇這種方式。最后的方式就是版本回退，當然了，前提是你提交信息必須簡潔明了，不然的話像上面的反面例子，鬼知道是哪個。
另外關於什么時候，提交，盡可能是完成一個新的功能或者是優化某個功能，解決某個bug等等就提交。但是這里有個前提就是，你本地必須測試沒有問題，否則那樣等於做無用工。
希望這篇文章能給大家帶來幫助。
本文轉載自：