生活不能隨意過，程式碼也不能隨意寫。
前一篇文章我們已經把專案搭建好了，那是不是馬上就開始寫頁面了呀？
NO！
無論在哪家公司，都會有相應的程式碼規範。新入職的員工往往第一步就要接受程式碼規範的學習。
既然是實戰專案，我們也得在寫頁面之前把相關的規範配置做好。
今天我們先來看看專案中git的使用及相關規範吧。
Git規範及專案配置
目的
- 統一團隊Git Commit標準，便於後續程式碼review、版本釋出、自動化生成change log；
- 可以提供更多更有效的歷史資訊，方便快速預覽以及配合cherry-pick快速合併程式碼；
- 團隊其他成員進行類
git blame時可以快速明白程式碼用意；
版本規範
1.分支
- master: 主分支(保護分支)，不能直接在master上進行修改程式碼和提交；
- develop: 測試分支，所以開發完成需要提交測試的功能合併到該分支；
- feature-*: 新功能開發分支，根據不同需求建立獨立的功能分支，開發完成後合併到develop分支；
- hotfix-*: bug修復分支，根據實際情況對已釋出的版本進行漏洞修復；
- release-*: 預釋出分支。
2.Tag
採用三段式，v版本.里程碑.序號，如v1.2.3
- 架構升級或架構重大調整，修改第1位
- 新功能上線或者模組大的調整，修改第2位
- bug修復上線，修改第3位
3.changelog
版本正式釋出後，需要生產changelog文件，便於後續問題追溯。
提交規範
Git commit日誌基本規範
每次提交，Commit message 都包括三個部分：Header，Body 和 Footer。
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
複製程式碼注意冒號後面有空格。
其中，Header 是必需的，Body 和 Footer 可以省略。
Header：
Header部分只有一行，包括三個欄位：type（必需）、scope（可選）和subject（必需）。
type
代表某次提交的型別，比如是修復一個bug還是增加一個新的feature。
所有的type型別如下：
- feat： 新增feature
- fix: 修復bug
- docs: 僅僅修改了文件，比如README, CHANGELOG等等
- style: 僅僅修改了空格、格式縮排等等，不改變程式碼邏輯
- refactor: 程式碼重構，沒有加新功能或者修復bug
- perf: 優化相關，比如提升效能、體驗
- test: 測試用例，包括單元測試、整合測試等
- revert: 回滾到上一個版本
- build: 影響構建系統或外部依賴項的更改
- ci: 主要目的是修改專案繼續整合流程
- chore: 不屬於以上型別的其他型別
scope
scope用於說明 commit 影響的範圍，比如資料層、控制層、檢視層等等，視專案不同而不同。
subject
subject是 commit 目的的簡短描述，不超過50個字元。 其他注意事項：
- 以動詞開頭，使用第一人稱現在時，比如change，而不是changed或changes
- 第一個字母小寫
- 結尾不加句號（.）
Body：
Body 部分是對本次 commit 的詳細描述，可以分成多行。
需要描述的資訊包括:
- 為什麼這個變更是必須的? 它可能是用來修復一個bug，增加一個feature，提升效能、可靠性、穩定性等等
- 他如何解決這個問題? 具體描述解決問題的步驟
- 是否存在副作用、風險?
有兩個注意點:
- 使用第一人稱現在時，比如使用change而不是changed或changes。
- 永遠別忘了第2行是空行
Footer：
如果需要的話可以新增一個連結到issue地址或者其它文件，或者關閉某個issue。
專案配置
既然規範已經有了，那我們就按照規範開始實戰吧。
首先我們新建兩個分支：
git branch develop
複製程式碼git branch feature-git提交規範
複製程式碼然後我們切換到新建的功能分支:
git checkout feature-git提交規範
複製程式碼接下來我們就來新增git提交資訊效驗的配置。
使用commitizen來執行規範
- 全域性安裝:
npm install -g commitizen
複製程式碼mac下需在前面加sudo
- 專案目錄下執行：
commitizen init cz-conventional-changelog --save --save-exact
複製程式碼配好後，之後用到git commit命令時，改為使用git cz。
這時，就會出現選項，用來生成符合格式的 Commit message。
好，我們把剛剛的改動提交一下吧。 先把修改加入暫存
git add .
複製程式碼使用git cz 代替 git commit
git cz
複製程式碼結果如下:
生成 Change log
因為我們的commit使用嚮導生成完全符合規範，所以釋出新版本時， 可以用指令碼自動生成Change log。
生成的文件包括以下三個部分：
- New features
- Bug fixes
- Breaking changes.
每個部分都會羅列相關的 commit ，並且有指向這些 commit 的連結。
當然，生成的文件允許手動修改，所以釋出前，你還可以新增其他內容。
conventional-changelog 就是生成 Change log 的工具.
執行下面的命令即可：
- 全域性安裝
npm install -g conventional-changelog-cli
複製程式碼- 專案目錄執行
conventional-changelog -p angular -i CHANGELOG.md -s -r 0
複製程式碼這時你會發現專案目錄裡面多了CHANGLOG.md檔案
我們可以把命令放在script裡面： 修改package.json檔案，在script中新增：
"version": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0 && git add CHANGELOG.md"
複製程式碼我們做一次提交來試試看:
git add .
git commit -m "feat: 新增生成changelog功能"
複製程式碼然後執行：
npm run version
複製程式碼之後我們看到CHANGELOG.md檔案有了我們的提交日誌：
注意，我之前提交過一次，但是type使用的是build，所以不會在日誌中體現。
最後我們再把CHANGELOG.md的變化做一次提交:
git commit -m "docs: 新增CHANGELOG.md檔案"
複製程式碼細心的朋友可能已經發現，這兩次提交我並沒有使用git cz而是為了方便直接使用了git commit -m ""這種形式，時刻記著提交資訊規範的話使用這種方式也沒問題，但是有時候難免失誤，比如不小心把feat打成feet，那如何防止失誤呢？來看看吧。
使用commitlint效驗提交資訊
- 首先還是安裝依賴：
npm install --save-dev @commitlint/{cli,config-conventional}
npm install --save-dev husky
複製程式碼@vue/cli-service 也會安裝 yorkie,但yorkie fork 自 husky 且並不和之後的版本相容。所以這裡我還是安裝了husky
- 在根目錄新建檔案
commitlint.config.js
module.exports = {
extends: ["@commitlint/config-conventional"],
rules: {
"type-enum": [
2,
"always",
["feat", "fix", "docs", "style", "refactor", "test", "chore", "revert"]
],
"subject-full-stop": [0, "never"],
"subject-case": [0, "never"]
}
};
複製程式碼- 在package.json中新增husky配置
"husky": {
"hooks": {
"commit-msg": "commitlint -e $HUSKY_GIT_PARAMS"
}
}
複製程式碼這樣就配好了，現在我們來測試一下：
上圖可以看到，當我type輸錯時會報錯，這樣我們就不怕不小心打錯自己沒注意到的情況啦。
修改之後成功提交。
合併提交
最後我們把我們今天的工作提交到github上吧
git checkout develop
git merge feature-git程式碼提交資訊審查
git checkout master
git merge develop
git push
複製程式碼小結
今天花了較大篇幅講解如何為何配置GIT提交規範及如何配置，實在是小肆深知在實際工作過程中遵守規範是多麼重要的一件事.
尤其是團隊開發或是開源專案，可以說一個程式設計師的程式碼素質從他的每一次提交記錄就能體現一二，所以還望大家能重視起來。
接下來幾篇小肆會為大家帶來程式碼效驗、自動格式化、手機端適配、判斷訪問客戶端型別等前期準備工作，關注我的公眾號"技術放肆聊"持續關注吧！
