目錄：
提交操作規范
為了保持分支提交歷史的清晰、獨立，在提交更改時，我們應做到：
- 每一個提交都應該是一個完整、獨立的變更單元；
- 撰寫符合提交說明規范 的提交說明信息；
- 對于修復錯別字、添加遺漏的更改等等之類的提交應與對應的提交合并，不應為其創建單獨的提交；
多個提交合并成一個的各種方法請看Git中合并多個提交的各種方法
提交說明規范
Git 每次提交代碼，都必須要寫 提交說明； Git 對 提交說明 的格式是沒有限制的，你想怎么寫就怎么寫，如下：
但是，類似這種沒有格式的提交說明有以下缺點：
- 不能很快分辨出提交的代碼是增加了新功能、還是修復了bug、還只是更新了文檔等等；
- 不能有效地過濾某一類提交，比如：只想查看修復bug類的提交；
- 不能根據需要過濾并導出提交信息，作為變更日志：比如，應用的升級的新功能說明、問題修復說明等等；
為了 方便 查看、過濾 提交說明，我需要將提交說明格式化、規范化；目前，有多種 提交說明 的寫法規范。但我推薦 Angular提交說明規范，這是目前使用最廣的寫法，比較合理和系統化，并且有配套的工具。
關于 Angular提交說明規范 的詳細文章請見：
下面是我對 Angular提交說明規范 一個匯總描述；
Angular提交說明規范
Angular提交說明的格式如下：
-
[]表示可選的； -
<>表示必須的；
<Type>[(Scope)]:<Subject>
<空一行>
[Body]
<空一行>
<Footer>
只有
Type和Subject是必須的，其它的都是可選的；提交說明包括三個部分：Header（第一行）、Body（可選） 和 Footer（可選），用空行分隔；其中 Body、Footer 都是可選的，可以省略；
任何一行都不得超過72、100個字符；這是為了避免自動換行影響美觀
-
Header：只占第一行，包括三個字段：Type（必需）、Scope（可選）和 Subject（必需）；
-
Type：必需；用于說明提交的類別，只允許使用下面7個標識：
- feat：新功能（feature）
- fix：修補bug
- doc：文檔（documentation），(很多規范里使用的是復數
docs，但我更建議使用doc) - style： 格式（不影響代碼運行的變動）
- refactor：重構（即不是新增功能，也不是修改bug的代碼變動）
- test：增加測試
- chore：構建過程或輔助工具的變動
如果type為feat和fix，則該 commit 將肯定出現在 Change log 之中。其他情況（doc、chore、style、refactor、test）由你決定，要不要放入 Change log，建議是不要。
提示： 為了醒目，也可以為每個 Type 分別指定一個 Emoji 表情，將其放在 Type 前面 或 后面； Scope：可選；用于說明提交的影響范圍，比如數據層、控制層、視圖層等等，視項目不同而不同。
-
Subject：提交目的 的簡短描述；要求如下：
- 不超過50個字符。
- 以動詞開頭，使用第一人稱現在時，比如 change，而不是 changed 或 changes
- 第一個字母小寫
- 結尾不加句號
.
-
-
Body：對本次提交的詳細描述，
- 可以分成多行。
- 使用第一人稱現在時，比如使用change而不是changed或changes。
- 應該說明代碼變動的動機，以及與以前行為的對比。
-
Footer：Footer 部分只用于兩種情況。
- 不兼容變動：如果當前代碼與上一個版本不兼容，則 Footer 部分以
BREAKING CHANGE開頭，后面是對變動的描述、以及變動理由和遷移方法。 - 關閉 Issue：如果當前 提交 針對某個 issue 的，那么可以在 Footer 部分用
Closes #234關閉這個 issue ；也可以用Closes #123, #245, #992一次關閉多個 issue ；
- 不兼容變動：如果當前代碼與上一個版本不兼容，則 Footer 部分以
-
特殊情況： 如果當前 提交 用于撤銷以前的 提交，則：
- Header 必須以
revert:開頭，后面跟著被撤銷的提交的 Header。 - Body 部分的格式是固定的，必須寫成
This reverts commit <hash>.，其中的hash是被撤銷的 提交 的 SHA 標識符。
如果當前提交 與 被撤銷的 提交，在同一個發布（release）里面，那么它們都不會出現在 Change log 里面。如果兩者在不同的發布，那么當前 commit，會出現在 Change log 的Reverts小標題下面。
- Header 必須以
