怎麼寫Git Commit Message呢? — 菜雞筆記
目錄
前言
這是菜雞筆記的首章，大概就是一些自己已經用了一陣子的工具或知識，突然發現好像自己用的不是這麼精透，又或者是自己接收到了一些有趣的事想和大家分享，應該都會出現在這個系列～
第一篇為大家帶來的是Git Commit Message，主要會寫這篇文章是因為自己也已經使用Git做版本控管的工具很長一段時間了，常常都會把自己的作品放到Github上。（當然有大有小拉XD 有時候只是怕自己程式碼不見就放上去
不過每次Git Commit Message的部分都是照著心情來寫，雖然說是有寫到重點和每次編輯的內容，不過向來都沒有一個制式的寫法。到了實習的公司以後，有了更多多人合作共編的經歷，主管給了我一些建議，如果說大家寫Git Commit Message都有類似的寫法的話，在後續做管理的話，Git Commit Message才可以發揮較大的效益，可以提升可讀性！又或者5年後突然想要回顧過去的coding，才不會花上太多時間重新理解～
說明
Commit Message並非只是記錄做了什麼事，應該要包含為什麼做這件事以及怎麼做到的！（正所謂Why、What和How的概念
以下舉個例子，如果今天你的程式中想要多產出一份output～
應該就可以很明顯的發現差別了XD
- 不好的示範：Update test.py
- 優秀的示範：<FEAT>Add filename.csv output:for next step input
格式
閱讀了參考文章的第一篇，覺得實在是太好用了，所以搬來分享給大家！
姑且也可以算是一種規範的格式就是了～
Header: <type>(<scope>): <subject>
- type:commit的類別：feat, fix, docs, style, refactor, test, chore，必要欄位。
- scope:commit的範圍，取決於項目和所使用的技術，是可選欄位。
- subject:commit的簡短描述，不要超過50個字元。
<< BLANK LINE >>
Body: 72-character wrapped. This should answer:
* Body部份是對本次Commit的詳細描述，可以分成多行，每行最多72個字元。
* 說明程式碼變動的項目與原因，還有與先前行為的對比。
<< BLANK LINE >>
Footer:
- 填寫任務編號（如果有的話,issue的那個）.
- BREAKING CHANGE（可忽略），記錄不兼容的變動，
以 BREAKING CHANGE: 開頭，後面是對變動的描述、以及變動原因和遷移方法。☞如果覺得subject很難在50個字元內編寫完畢，可以回頭審視本次的編輯內容，也要盡可能地將不同的編輯目的給分開commit。
種類
feat– 新增/修改功能fix– 修復錯誤chore– 不影響程式碼運行，建構程序或輔助工具的變動，例如修改 config等。refactor– 重構程式碼（不修復錯誤也不添加功能）docs– 更新文檔style– 不影響程式碼含義的更改，可能和格式有關，例如空格、缺少分號等。test– 測試perf– 效能優化revert– 回復版本ci– 持續集成相關➛貌似不常使用，幾乎沒看見過build– 影響構建系統或外部依賴項的更改➛貌似不常使用，幾乎也沒看見過
範例
（為了不要帶給大家錯誤的資訊，我決定先舉大神的做例子
- 編輯README.md文檔，增加了新的參考文章到新的編輯者中，issue是#780，並且編輯者是cz-conventional-changelog-with-jiraid-detection。
<DOCS>(README.md): add new reference to new adapter (#780)Adds `cz-conventional-changelog-with-jiraid-detection` to adapter list
2. 修正config loader的bug，是關於config file字元的錯誤，issue是584。必須確保是utf-8，否則就丟提醒。
<FIX>(config loader): deal with config file charset (#584)Make sure that config file charset is utf-8, or throw detail to notify
3. 不會影響程式碼運行，單純修改了套件（dependencies）版本，將semver改至7.3.7 version。
<CHORE>(deps): update dependency semver to v7.3.7從上面的範例可以發現，其實不一定要打到body或是footer的內容，所以是optional的，不過header的部分就很重要要遵照規範了。
然後作者本人我也沒有參與這個專案，但我真的只是透過commit message就了解修改了什麼內容～
結語
多花點時間研究Git Commit Message的奧妙，然後每次commit的時後也多再花一點點心思把它編輯完成，絕對是會比之後要code review的時候所花的經歷cp值高出世界無敵多的！不然每次回顧的時候都跟鬼一樣ＱＱ
而且不知道是不是因為有一咪咪的強迫症，回頭看的時候也覺得好整齊好漂亮＾＾
如果喜歡的話，幫我拍拍手吧！大感謝囉～
