原文：https://blog.csdn.net/samjustin1/article/details/81737284?depth_1-utm_source=distribute.pc_relevant.none-task&utm_source=distribute.pc_relevant.none-task
feat： 新增 feature
fix: 修複 bug
docs: 僅僅修改了文檔，比如 README, CHANGELOG, CONTRIBUTE等等
style: 僅僅修改了空格、格式縮進、逗号等等，不改變代碼邏輯
refactor: 代碼重構，沒有加新功能或者修複 bug
perf: 優化相關，比如提升性能、體驗
test: 測試用例，包括單元測試、內建測試等
chore: 改變建構流程、或者增加依賴庫、工具等
revert: 復原到上一個版本
Git分支與版本釋出規範
基本原則：master為保護分支，不直接在master上進行代碼修改和送出。
開發日常需求或者項目時，從master分支上checkout一個feature分支進行開發或者bugfix分支進行bug修複，功能測試完畢并且項目釋出上線後，将feature分支合并到主幹master，并且打Tag釋出，最後删除開發分支。分支命名規範：
分支版本命名規則：分支類型 _ 分支釋出時間 _ 分支功能。比如：feature_20170401_fairy_flower
分支類型包括：feature、 bugfix、refactor三種類型，即新功能開發、bug修複和代碼重構
時間使用年月日進行命名，不足2位補0
分支功能命名使用snake case命名法，即下劃線命名。
Tag包括3位版本，字首使用v。比如v1.2.31。Tag命名規範：
新功能開發使用第2位版本号，bug修複使用第3位版本号
核心基礎庫或者Node中間價可以在大版本釋出請使用灰階版本号，在版本後面加上字尾，用中劃線分隔。alpha或者belta後面加上次數，即第幾次alpha：
v2.0.0-alpha.1
v2.0.0-belta.1
版本正式釋出前需要生成changelog文檔，然後再釋出上線
