該指南是你在專案進行過程中所需遵守的官方指南。優達學城的評估人員會根據該指南為你的專案打分。在前端網頁開發的世界中，有很「最佳」樣式供你選擇。因此，為了減少學生在專案過程中因選擇何種樣式所產生的困惑，我們強烈建議所有學生在其專案中遵循這個樣式指南。
提交資訊由三個不同的部分構成，這些部分均由空行分隔：標題、可選的訊息體和可選的注釋。其布局大致如此：
型別：主題
訊息正文 注釋
標題由訊息型別和主題構成。
型別位於在標題內，有以下幾種可能：
主題不得超過50個字元，首字母大寫，末尾不加句號。
以祈使語氣描述提交的任務，而不是其已完成的任務。例如，使用
change
...，而不是 changed 或 changes 。
並不是所有的提交資訊都複雜到需要主體，因此這是可選內容，僅在提交資訊需要一定的解釋和語境時使用。訊息體是用於解釋提交任務的
內容和原因
，而不是方法。
在編寫正文時，需要在標題和正文間加乙個空行，且每行的內容應控制在72個字元內。
注釋是可選內容，用於引用問題跟蹤的 id 。
feat:
總結變動的內容，保持在50個字元內
如有需要，使用更詳細的說明性文字，將其大概控制在72個字元。在部分語境中，第一行被視為提交資訊的主題，餘下的文字被視為主體。分隔總結與主體的空行十分重要（除非你完全忽略主體）；否則`log`、`shortlog`和`rebase`等多個工具容易發生混淆。
解釋該提交資訊所解決的問題，說明你進行該變動的原因，而不是方法（**本身可以解釋方法）。
該變動是否存在***或其他直覺性後果？在這裡進行解釋。
後續段落前需加空行。
可以列出要點
- 通常情況下，要點會使用空格加上連字元或星號，中間用空行分隔，但該規定存在差別。
如果你使用問題追蹤，將其引用放在末尾，例如：
解決了問題：#123
另見：#456, #789
git 提交資訊模板
英文源 首字母大寫的摘要 不多於 50 個字元 如果必要的話，加入更詳細的解釋文字。在大概 72 個字元的時候換行。在某些情形下，第一行被當作一封電子郵件的標題，剩下的文字作為正文。分隔摘要與正文的空行是必須的 除非你完全省略正文 如果你將兩者混在一起，那麼類似變基等工具無法正常工作。使用指令式的語...
git提交資訊校驗格式
老大前兩天要求git提交時填寫的資訊必須是以某個格式提交，比如改bug需要以 fixbug 開頭。但是有時候一懶就忘了加這些字首了。所以想到git鉤子，可以在提交之前寫乙個校驗指令碼。git專案下的 git hooks commit msg檔案內容更改為 test grep 1 解釋一下語句涉及的命...
GIT 修改GIT提交人記錄資訊
場景 公司內部有git賬號，以工號命名，個人賬號參與開源專案 提交開源專案的時候使用者名稱沒切換成個人賬戶，導致專案都是工號的提交記錄，違反了公司規定。參考 侵刪。git clone bare如 cd ant design.gitcopy以下指令碼到記事本，修改old name correct na...