摘要：既然是實(shí)戰(zhàn)項(xiàng)目，我們也得在寫頁面之前把相關(guān)的規(guī)范配置做好。使用來執(zhí)行規(guī)范全局安裝下需在前面加項(xiàng)目目錄下執(zhí)行配好后，之后用到命令時(shí)，改為使用。使用效驗(yàn)提交信息首先還是安裝依賴也會(huì)安裝但自且并不和之后的版本兼容。

生活不能隨意過，代碼也不能隨意寫。

前一篇文章我們已經(jīng)把項(xiàng)目搭建好了，那是不是馬上就開始寫頁面了呀？

NO！

無論在哪家公司，都會(huì)有相應(yīng)的代碼規(guī)范。新入職的員工往往第一步就要接受代碼規(guī)范的學(xué)習(xí)。

既然是實(shí)戰(zhàn)項(xiàng)目，我們也得在寫頁面之前把相關(guān)的規(guī)范配置做好。

今天我們先來看看項(xiàng)目中g(shù)it的使用及相關(guān)規(guī)范吧。

統(tǒng)一團(tuán)隊(duì)Git Commit標(biāo)準(zhǔn)，便于后續(xù)代碼review、版本發(fā)布、自動(dòng)化生成change log；

可以提供更多更有效的歷史信息，方便快速預(yù)覽以及配合cherry-pick快速合并代碼；

團(tuán)隊(duì)其他成員進(jìn)行類git blame時(shí)可以快速明白代碼用意；

master: 主分支(保護(hù)分支)，不能直接在master上進(jìn)行修改代碼和提交；

develop: 測(cè)試分支，所以開發(fā)完成需要提交測(cè)試的功能合并到該分支；

feature-*: 新功能開發(fā)分支，根據(jù)不同需求創(chuàng)建獨(dú)立的功能分支，開發(fā)完成后合并到develop分支；

hotfix-*: bug修復(fù)分支，根據(jù)實(shí)際情況對(duì)已發(fā)布的版本進(jìn)行漏洞修復(fù)；

release-*: 預(yù)發(fā)布分支。

采用三段式，v版本.里程碑.序號(hào)，如v1.2.3

架構(gòu)升級(jí)或架構(gòu)重大調(diào)整，修改第1位

新功能上線或者模塊大的調(diào)整，修改第2位

bug修復(fù)上線，修改第3位

版本正式發(fā)布后，需要生產(chǎn)changelog文檔，便于后續(xù)問題追溯。

每次提交，Commit message 都包括三個(gè)部分：Header，Body 和 Footer。

(): 
// 空一行

// 空一行

注意冒號(hào)后面有空格。

其中，Header 是必需的，Body 和 Footer 可以省略。

Header部分只有一行，包括三個(gè)字段：type（必需）、scope（可選）和subject（必需）。

type

代表某次提交的類型，比如是修復(fù)一個(gè)bug還是增加一個(gè)新的feature。

所有的type類型如下：

feat： 新增feature

fix: 修復(fù)bug

docs: 僅僅修改了文檔，比如README, CHANGELOG等等

style: 僅僅修改了空格、格式縮進(jìn)等等，不改變代碼邏輯

refactor: 代碼重構(gòu)，沒有加新功能或者修復(fù)bug

perf: 優(yōu)化相關(guān)，比如提升性能、體驗(yàn)

test: 測(cè)試用例，包括單元測(cè)試、集成測(cè)試等

revert: 回滾到上一個(gè)版本

build: 影響構(gòu)建系統(tǒng)或外部依賴項(xiàng)的更改

ci: 主要目的是修改項(xiàng)目繼續(xù)集成流程

chore: 不屬于以上類型的其他類型

scope

scope用于說明 commit 影響的范圍，比如數(shù)據(jù)層、控制層、視圖層等等，視項(xiàng)目不同而不同。

subject

subject是 commit 目的的簡(jiǎn)短描述，不超過50個(gè)字符。
其他注意事項(xiàng)：

以動(dòng)詞開頭，使用第一人稱現(xiàn)在時(shí)，比如change，而不是changed或changes

第一個(gè)字母小寫

結(jié)尾不加句號(hào)（.）

Body 部分是對(duì)本次 commit 的詳細(xì)描述，可以分成多行。

需要描述的信息包括:

為什么這個(gè)變更是必須的? 它可能是用來修復(fù)一個(gè)bug，增加一個(gè)feature，提升性能、可靠性、穩(wěn)定性等等

他如何解決這個(gè)問題? 具體描述解決問題的步驟

是否存在副作用、風(fēng)險(xiǎn)?

有兩個(gè)注意點(diǎn):

使用第一人稱現(xiàn)在時(shí)，比如使用change而不是changed或changes。

永遠(yuǎn)別忘了第2行是空行

如果需要的話可以添加一個(gè)鏈接到issue地址或者其它文檔，或者關(guān)閉某個(gè)issue。

既然規(guī)范已經(jīng)有了，那我們就按照規(guī)范開始實(shí)戰(zhàn)吧。

首先我們新建兩個(gè)分支：

git branch develop

git branch feature-git提交規(guī)范

然后我們切換到新建的功能分支:

git checkout feature-git提交規(guī)范

接下來我們就來添加git提交信息效驗(yàn)的配置。

全局安裝:

npm install -g commitizen

mac下需在前面加sudo

項(xiàng)目目錄下執(zhí)行：

commitizen init cz-conventional-changelog --save --save-exact

配好后，之后用到git commit命令時(shí)，改為使用git cz。

這時(shí)，就會(huì)出現(xiàn)選項(xiàng)，用來生成符合格式的 Commit message。

好，我們把剛剛的改動(dòng)提交一下吧。
先把修改加入暫存

git add .

使用git cz 代替 git commit

git cz

結(jié)果如下:

因?yàn)槲覀兊腸ommit使用向?qū)赏耆弦?guī)范，所以發(fā)布新版本時(shí)， 可以用腳本自動(dòng)生成Change log。

生成的文檔包括以下三個(gè)部分：

New features

Bug fixes

Breaking changes.

每個(gè)部分都會(huì)羅列相關(guān)的 commit ，并且有指向這些 commit 的鏈接。

當(dāng)然，生成的文檔允許手動(dòng)修改，所以發(fā)布前，你還可以添加其他內(nèi)容。
conventional-changelog 就是生成 Change log 的工具.

運(yùn)行下面的命令即可：

全局安裝

npm install -g conventional-changelog-cli

項(xiàng)目目錄運(yùn)行

conventional-changelog -p angular -i CHANGELOG.md -s -r 0

這時(shí)你會(huì)發(fā)現(xiàn)項(xiàng)目目錄里面多了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功能"

然后運(yùn)行：

npm run version

之后我們看到CHANGELOG.md文件有了我們的提交日志：

注意，我之前提交過一次，但是type使用的是build，所以不會(huì)在日志中體現(xiàn)。

最后我們?cè)侔袰HANGELOG.md的變化做一次提交:

git commit -m "docs: 添加CHANGELOG.md文件"

細(xì)心的朋友可能已經(jīng)發(fā)現(xiàn)，這兩次提交我并沒有使用git cz而是為了方便直接使用了git commit -m ""這種形式，時(shí)刻記著提交信息規(guī)范的話使用這種方式也沒問題，但是有時(shí)候難免失誤，比如不小心把feat打成feet，那如何防止失誤呢？來看看吧。

首先還是安裝依賴：

npm install --save-dev @commitlint/{cli,config-conventional}
npm install --save-dev husky

@vue/cli-service 也會(huì)安裝 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"
    }
  }

這樣就配好了，現(xiàn)在我們來測(cè)試一下：

上圖可以看到，當(dāng)我type輸錯(cuò)時(shí)會(huì)報(bào)錯(cuò)，這樣我們就不怕不小心打錯(cuò)自己沒注意到的情況啦。

修改之后成功提交。

最后我們把我們今天的工作提交到github上吧

git checkout develop
git merge feature-git代碼提交信息審查
git checkout master
git merge develop
git push

今天花了較大篇幅講解如何為何配置GIT提交規(guī)范及如何配置，實(shí)在是小肆深知在實(shí)際工作過程中遵守規(guī)范是多么重要的一件事.

尤其是團(tuán)隊(duì)開發(fā)或是開源項(xiàng)目，可以說一個(gè)程序員的代碼素質(zhì)從他的每一次提交記錄就能體現(xiàn)一二，所以還望大家能重視起來。

接下來幾篇小肆?xí)榇蠹規(guī)泶a效驗(yàn)、自動(dòng)格式化、手機(jī)端適配、判斷訪問客戶端類型等前期準(zhǔn)備工作，關(guān)注我的公眾號(hào)"技術(shù)放肆聊"持續(xù)關(guān)注吧！

用vue-cli3從0到1做一個(gè)完整功能手機(jī)站（一）

從0到1開發(fā)實(shí)戰(zhàn)手機(jī)站（二）：Git提交規(guī)范配置

從0到1使用VUE-CLI3開發(fā)實(shí)戰(zhàn)（三）: ES6知識(shí)儲(chǔ)備