# 版本控制 Message 怎麼寫會比較好
# Commit 提交
對這次的修改,提交成為一個版本,並且會透過 Message 形成一個該版本的修改或者提交訊息。
這時候如何讓跟你合作的開發者們快速的了解你這次的版本做了哪些事情就很重要了
不然你的合作開發者們會森戚戚
# 複習一下
假設你完成了一部分程式且已經將目標檔案加入到 Stage 裡面
1 | git add <某些檔案> |
接下來就可以提交成一個版本了,怎麼寫 Message 呢?
1 | git commit -m "<Your Message>" |
# 怎麼將 Message 寫的好
- 還沒進行版本控制前,在你的程式碼多寫註解
- 解決一次 Issue 時不應該把所有修正只提交成一個版本,請拆分成不同功能或修正進行版本提交
- 每次提交都是針對檔案進行說明,讓其他人快速進入狀況
- 每次根據修復的 Issue 版本 將 Commit 加入 Issue 編號
Git 不僅僅是程式碼倉庫,他的本質還是版本控制 (請好好牢記)
# 參考 Commit Message 規範
由 AngularJS Commit Conventions 提出的規範
簡單說明
就是要有 Header,Body,Footer (好像網頁喔)
1 | fix: 解決訂單模型 ORM 存取優化的問題 |
上面的例子我們能夠清楚的了解該版本做了與解決了甚麼事情
1 | header: |
# 規範組成
Header: <類別>(< 範圍 >): < 主旨 >
- 類別:代表 commit 的類別:feat, fix, docs, style, refactor, test, chore,必要欄位。
- [Optional] 範圍 代表該版本影響的範圍,例如資料庫、控制層、模板層等等,視專案不同而不同,為可選欄位。
- 主旨 代表此版本的簡短描述,不要超過 50 個字元,結尾不要加句號,為必要欄位。
Body:
- 每一行不超過 72 個字元,可多行描述變動項目與原因,與前一版本的差異
Footer:
- [Optional] 填寫 Issue number.
- [Optional] 填寫不兼容變動部分。
- 格式 BREAKING CHANGE:
# Message 種類
- feat: 新增功能 feature
- fix: 修復 fix
- docs: 文件 document
- style: 格式風格 (不影響程式運作與邏輯)
- refactor: 重構 非新增功能與修復
- perf: 改善效能
- test: 增加測試
- chore: 建構或輔助工具的變動
- revert: 撤銷之前的 Commit
參考文章