前端工程化（2）：快速搭建基於angular團隊代碼提交規範的工做流

本文的目的是爲了給想要快速搭建一套業內流行的angular團隊代碼提交規範（不是angular團隊編寫代碼的規範）的小夥伴們提供一個簡單清晰直白的教程。文章的內容不會深究每一個環節的細節，可是會用通俗的話語讓須要的小夥伴們瞭解每一個環節的含義和做用，從而能作到從0到1的搭建起代碼提交的工做流。

1. 格式化 commit message

commit message的重要性我就不在這強調了，咱們常規提交代碼都是經過git commit -m "xxx"附上一句話來描述這次代碼的改動，這樣的方式對於一些影響範圍大或者broken式的改動來講太過於簡單隨意。每一個人都有本身習慣的提交代碼方式，因此咱們須要藉助一個工具來生成符合規範的commit message並約束提交的人。

commitizen是一個格式化commit message的工具，能夠約束提交者按照制定的規範一步一步的填寫commit message。

局部安裝

npm i -D commitizen

配置：

package.json中寫入：

"script": {
    ...,
    "commit": "git-cz",
}
複製代碼

這樣咱們就能夠藉助commitizen提供的git-cz，用npm run commit命令來替代git commit命令。

2. 採用 angular 團隊代碼提交規範

咱們已經把能夠生成指定commit message的工具commitizen安裝好了，接下來要作的就是爲commitizen制定一套填寫規範。

cz-conventional-changelog is a commitizen adapter for the angular preset of conventional-changelog （一套適用於commitizen的angular團隊規範）。目前採用比較普遍，那咱們就直接給commitizen引用這套規範了。

局部安裝

npm i -D cz-conventional-changelog

配置：

package.json中寫入：

"config": {
    "commitizen": {
        "path": "node_modules/cz-conventional-changelog"
    }
}
複製代碼

安裝配置好之後，執行npm run commit就會出現以下引導式填寫：

3. 校驗 commit message

雖然以前兩步已經約束了一套代碼提交規範，可是仍是有人不按照規範提交代碼怎麼辦呢？這個時候就須要commitlint來幫助咱們校驗commit message，拒毫不符合規範的commit message。

與eslint相似，commitlint也須要一份校驗的配置。彆着急，這裏有一份與cz-conventional-changelog規範（angular團隊規範）配套的校驗配置@commitlint/config-conventional來幫助咱們檢驗commit message的合規性。

局部安裝

npm i -D @commitlint/config-conventional @commitlint/cli

配置

安裝完成之後，同時須要在項目根目錄下建立配置文件commit.config.js或者.commitlintrc.js並寫入：

module.exports = { 
    extends: [
        '@commitlint/config-conventional'
    ]
}
複製代碼

或者在package.json中寫入：

"commitlint": {
    "extends": [
        "@commitlint/config-conventional"
    ]
  },
複製代碼

commitlint就能夠運用config-conventional這套校驗配置。

4. 配置校驗時機

到了第三步咱們的代碼提交約束規範已經基本成型了，最後一步要作的就是配置觸發commit message校驗的時機。

校驗commit message的最佳姿式是git hook和husky的結合。

husky（哈士奇）是個什麼東西呢？簡單來講就是個能讓你在每一個git鉤子中配置相應行爲的一個工具。

局部安裝

npm install husky --save-dev

配置

安裝完成之後，同時須要在項目根目錄下建立配置文件.huskyrc或者.huskyrc.js文件並寫入：

{
    "husky": {
        "hooks": {
            ...,
            "commit-msg": "commitlint -e $GIT_PARAMS"
        }
    }
}
複製代碼

或者在package.json中寫入：

"husky": {
    "hooks": {
        ...,
        "commit-msg": "commitlint -e $GIT_PARAMS"
    }
}
複製代碼

在git commit-msg這個鉤子中會觸發commitlint的操做。

5. 自動化代碼檢查

通過前三步已經打造好了基於angular團隊代碼提交規範的工做流了，可是若是咱們還想在校驗commit message的規範性的同時，校驗這次提交代碼的正確性呢？

藉助 lint-staged 可讓你每次只對你這次提交所在暫存區的文件（git add後的文件）進行一系列的檢查、修復、格式化操等做。

局部安裝

npm install -D lint-staged

配置

安裝完成之後，同時須要在項目根目錄下建立配置文件.lintstagedrc並寫入：

{
  "*.{js,vue}": [
    "eslint --fix",
    "git add"
  ],
  "*.{html,vue,css,sass,scss}": [
    "stylelint --fix",
    "git add"
  ]
}
複製代碼

或者在package.json中寫入：

"lint-staged": {
    "*.{js,vue}": [
    "eslint --fix",
    "git add"
  ],
  "*.{html,vue,css,sass,scss}": [
    "stylelint --fix",
    "git add"
  ]
}
複製代碼

在第三步建立的husky配置文件進行補充：

"husky": {
    "hooks": {
        "pre-commit": "lint-staged",
        "commit-msg": "commitlint -e $GIT_PARAMS"
    }
}
複製代碼

在pre-commit這個鉤子中，lint-staged會執行.lintstagedrc配置的操做（列出來的配置的意思是對本次提交的js或者vue文件進行eslint檢查並修復，而且把修復事後的文件再從新提交到暫存區）。

6. 版本發佈

對於每次項目新版本的發佈，咱們須要更新相應的版本號並記錄其中的改變。能夠藉助 standard-version 工具，來替代npm run version，並自動生成CHANGELOG。

局部安裝

npm install standard-version --save-dev
複製代碼

配置

"scripts": {
    "release": "standard-version",
    ...
 }
複製代碼

執行npm run release指令實際執行了五個動做：

1. 修改package.json中的版本號
2. 修改package-lock.json中的版本號
3. 生成CHANGELOG.md文件
4. 提交package.json、package-lock.json、CHANGELOG.md文件
5. 給此次提交記錄打上tag

若是發佈的是首個版本，則能夠運行以下指令：

npm run release -- --firse-release
複製代碼

若是須要發佈預發佈版本，則可使用--prerelease/-p標誌來添加預發佈版本號：

# 當前版本爲 1.0.0
npm run release -- --prerelease  # 版本爲 1.0.1-0
npm run release -- --prerelease beta  # 版本爲 1.0.1-beta.1
複製代碼

若是是正常的版本迭代，則可使用--release-as/-r標誌來指定版本：

# 當前版本爲 1.0.0
npm run release -- --release-as patch  # 版本爲 1.0.1，npm run release默認行爲
npm run release -- --release-as minor  # 版本爲 1.1.0
npm run release -- --release-as major  # 版本爲 2.0.0
npm run release -- --release-as 2.0.1  # 版本爲 2.0.1
npm run release -- --release-as 2.0.1-alpha.0  # 版本爲 2.0.1-alpha.0
複製代碼

通常項目要上線新版本的時候，須要把release分支合到master，合完分支之後執行npm run release指令給此次發佈打上tag並記錄修改是一個良好的維護版本迭代的好習慣。

最後

一個完整的基於angular團隊代碼提交規範的工做流已經打造完成，若是有不適應angular這套規範的話也能夠自定義一套規範，這裏就再也不贅述了。固然，有的小夥伴以爲這麼寫commit很麻煩，可是一個好的提交規範習慣有助於整個團隊在項目中高效率的開發，因此趕忙在本身項目中用起來吧！