>譯   原文：https://dev.to/chrissiemhrk/git-commit-message-5e21 
提交資訊是對提交之前新增和更改的檔案所做的更改的簡短描述。 良好的提交資訊不僅對你所參與的專案上其它的團隊成員很重要，對你自己而言也很重要，你需要跟蹤所有提交，並確切知道在提交期間發生的變動。 即使你開發的是個人專案，我也建議你開始養成編寫良好的提交資訊的習慣。 這是我慣用的格式（可以隨著你的個人習慣和公司來改變）： ```bash type: subject body (可選) footer (可選) ```
# 1. Type * feat ：新功能 * fix : bug修復 * docs :文件變更 * style :與樣式相關的所有變動 * refactor :既不是bug修復也未新增功能的程式碼更改 * test :與測試有關所有變動 * chore :改變了構建任務，程式包管理器配置等
# 2. Subject 它應該包含對所做更改的簡短描述。長度不能超過50個字元，應以大寫字母開頭，命令式的語法。“Add”，而不是 “Added” 或 “Adds”。
# 3. Body 正文用於說明你進行了哪些更改以及進行更改的原因。並非所有提交都很複雜，需要一個正文，尤其是如果你僅是開發一個個人的專案，因此正文是可選的。
# 4. Footer 頁尾也是可選的，主要在你使用issue追蹤引用issue ID時使用。
這是Udacity學生git 提交資訊的例子[Udacity Git Commit Message Style Guide](https://udacity.github.io/git-styleguide/)

feat: 少於50個字元的更改概括。

如有必要，提供更詳細的說明文字，約72字元左右。在某些情況下，第一行被視為提交的主題，其餘文字作為正文。 將摘要與正文分開的空行至關重要（除非沒有正文）；各種工具，例如 log，shortlog和rebase，如果同時執行兩者，可能會造成混亂。

解釋該提交解決的問題。注意說明為什麼做這個更改（程式碼作了註釋）。另一方面，是否會導致負面的作用或其他不直觀的後果？這也是需要說明的地方。

空白行之後是其它段落。

- 專案要點也可以加進來
- 通常在專案符號前使用連字元或星號，用一個空格隔開，中間有空白行，但是約定在這裡變化

如果你使用issue追蹤，可以在footer中寫上對issue的關聯，就像這樣：

Resolves: #123See
also: #456, #789

這是一個實際的例子： ```bash docs: Fix typo in README.md ```

---

正文之外同樣有一些有意思的評論（歪果仁會玩啊）：

---

簡短明瞭，感謝你的這篇文章！ 我傾向於使用表情符號作為型別——一看就顯示了提交的型別，例如： ➕：heavy_plus_sign: 新增檔案或實現功能時