從0到1開發實戰手機站（二）：Git提交規範配置

時間 2019-11-08

標籤開發實戰手機 git 提交規範配置欄目 Git 简体版

原文原文鏈接

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

前一篇文章咱們已經把項目搭建好了，那是否是立刻就開始寫頁面了呀？ios

NO！git

不管在哪家公司，都會有相應的代碼規範。新入職的員工每每第一步就要接受代碼規範的學習。程序員

既然是實戰項目，咱們也得在寫頁面以前把相關的規範配置作好。github

今天咱們先來看看項目中git的使用及相關規範吧。vue-cli

Git規範及項目配置

目的

統一團隊Git Commit標準，便於後續代碼review、版本發佈、自動化生成change log；
能夠提供更多更有效的歷史信息，方便快速預覽以及配合cherry-pick快速合併代碼；
團隊其餘成員進行類git blame時能夠快速明白代碼用意；

版本規範

1.分支

master: 主分支(保護分支)，不能直接在master上進行修改代碼和提交；
develop: 測試分支，因此開發完成須要提交測試的功能合併到該分支；
feature-*: 新功能開發分支，根據不一樣需求建立獨立的功能分支，開發完成後合併到develop分支；
hotfix-*: bug修復分支，根據實際狀況對已發佈的版本進行漏洞修復；
release-*: 預發佈分支。

2.Tag

採用三段式，v版本.里程碑.序號，如v1.2.3shell

架構升級或架構重大調整，修改第1位
新功能上線或者模塊大的調整，修改第2位
bug修復上線，修改第3位

3.changelog

版本正式發佈後，須要生產changelog文檔，便於後續問題追溯。npm

提交規範

Git commit日誌基本規範

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

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
複製代碼

注意冒號後面有空格。bash

其中，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提交規範及如何配置，實在是小肆深知在實際工做過程當中遵照規範是多麼重要的一件事.

尤爲是團隊開發或是開源項目，能夠說一個程序員的代碼素質從他的每一次提交記錄就能體現一二，因此還望你們能重視起來。

接下來幾篇小肆會爲你們帶來代碼效驗、自動格式化、手機端適配、判斷訪問客戶端類型等前期準備工做，關注個人公衆號"技術放肆聊"持續關注吧！

前置閱讀：

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。