規(guī)范 GIT 代碼提交信息 & 自動化版本管理

猿友 2020-10-21 14:27:50 瀏覽數(shù) (3633)

反饋

前言

git作為一個開發(fā)人員必不可少的工具，代碼提交也是日常一個非常頻繁的操作，如果你或你的團隊目前對提交信息還沒有一個規(guī)范或約束，那么你有必要看看本文的內(nèi)容了。

為什么要規(guī)范提交信息

首先規(guī)范提交信息肯定是有必要的，簡單總結(jié)下幾點好處：

讓項目的維護或使用人員能了解提交了哪些更改
清晰的歷史記錄，可能某天自己就需要查到呢
規(guī)范的提交記錄可用于自動生成修改日志(CHANGELOG.MD)
基于提交類型，觸發(fā)構(gòu)建和部署流程

使用什么規(guī)范

Conventional Commits(約定式提交規(guī)范)，是目前使用最廣泛的提交信息規(guī)范，其主要受AngularJS規(guī)范的啟發(fā),下面是一個規(guī)范信息的結(jié)構(gòu)：

[optional scope]: 
//空一行
[optional body]
//空一行
[optional footer(s)]

規(guī)范說明

type 提交的類別，必須是以下類型中的一個

feat：增加一個新功能
fix：修復(fù)bug
docs：只修改了文檔
style：做了不影響代碼含義的修改，空格、格式化、缺少分號等等
refactor：代碼重構(gòu)，既不是修復(fù)bug，也不是新功能的修改
perf：改進性能的代碼
test：增加測試或更新已有的測試
chore：構(gòu)建或輔助工具或依賴庫的更新

scope 可選，表示影響的范圍、功能、模塊

subject 必填，簡單說明，不超過 50個字

body 選填，用于填寫更詳細的描述

footer 選填，用于填關(guān)聯(lián)issus,或BREAK CHANGE

BREAKING CHANGE

必須是大寫，表示引入了破壞性 API 變更，通常是一個大版本的改動，BREAKING CHANGE: 之后必須提供描述，下面一個包含破壞性變更的提交示例

feat: allow provided config object to extend other configs


BREAKING CHANGE: `extends` key in config file is now used for extending other config files

更詳細的說明請看約定式提交規(guī)范

如何約束規(guī)范

怎么確保每個提交都能符合規(guī)范呢，最好的方式就是通過工具來生成和校驗，commitizen是一個nodejs命令行工具，通過交互的方式，生成符合規(guī)范的git commit，界面如下：

開始安裝:

# 全局安裝
npm install -g commitizen 
# 或者本地安裝
$ npm install --save-dev commitizen
# 安裝適配器
npm install cz-conventional-changelog

packages.json在配置文件中指定使用哪種規(guī)范

...
  "config": {
    "commitizen": {
      "path": "cz-conventional-changelog"
    }
  }

安裝完成后可以使用git cz 來代替git commit,然后根據(jù)提示一步步輸入即可

格式校驗commitlint

可能你不想每次都通過交互界面來生成，還是想使用git commit -m 'message'，那么為了確保信息的正確性，可以結(jié)合husky對提交的信息進行格式驗證

安裝依賴

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

添加 commitlint.config.js文件到項目

echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
?``` 
`package.json`配置
#git提交驗證
“husky”: {
“hooks”: {
“commit-msg”: “commitlint -E HUSKY_GIT_PARAMS”
}
},

OK到這一步就完成了，最后給你項目 README.MD 加上一個commitizen-friendly的標(biāo)識吧

[![Commitizen friendly](https://img.shields.io/badge/commitizen-friendly-brightgreen.svg) _blank](http://commitizen.github.io/cz-cli/)


## 自動版本管理和生成CHANGELOG


規(guī)范化的提交信息除了能很好描述項目的修改，還有一個很好的作用就是能根據(jù)提交記錄來生成CHANGELOG.MD和自動生成版本號等功能。




### standard-version


一個用于生成`CHANGELOG.md`和進行`SemVer(語義化版本號)`發(fā)版的命令行工具


主要功能：
* 自動修改最新版本號，可以是`package.json`或者自定義一個文件
* 讀取最新版本號，創(chuàng)建一個最新的`git tag`
* 根據(jù)提交信息，生成`CHANGELOG.md`
* 創(chuàng)建一個新提交包括 `CHANGELOG.md`和`package.json`




### 語義化版本控制(SemVer)


先簡單了解下什么是語義化的版本控制，其是由`GitHub`發(fā)起的一份用于規(guī)范版本號遞增的規(guī)則，
##### 版本格式
主版本號.次版本號.修訂號，版本號遞增規(guī)則如下：


* 主版本號(major)：當(dāng)你做了不兼容的 API 修改，
* 次版本號(minor)：當(dāng)你做了向下兼容的功能性新增，可以理解為Feature版本，
* 修訂號(patch)：當(dāng)你做了向下兼容的問題修正，可以理解為Bug fix版本。


先行版本號可以加到“主版本號.次版本號.修訂號”的后面，作為延伸。


##### 先行版本
當(dāng)即將發(fā)布大版本改動前，但是又不能保證這個版本的功能 100% 正常，這個時候可以發(fā)布先行版本：


* alpha: 內(nèi)部版本
* beta: 公測版本
* rc: 候選版本(Release candiate)


比如：1.0.0-alpha.0,1.0.0-alpha.1,1.0.0-rc.0,1.0.0-rc.1等。


 `standard-version` 會根據(jù)提交的信息類型來自動更改對應(yīng)的版本號,如下:
* feat: 次版本(minor)+1
* fix: 修訂號(patch) +1
* BREAK CHANGE: 主板號(marjor) +1


> `standard-verstion` 生成的`CHANGELOG`只會包含`feat`,`fix`,`BREACK-CHANGE`類型的提交記錄




#### 使用
?``` bash
npm i --save-dev standard-version

添加npm script

{
 scripts:{
   "release": "standard-version",
   "release:alpha": "standard-version --prerelease alpha",
   "release:rc": "standard-version --prerelease rc"
  }
}

執(zhí)行：

# npm run script
npm run release
# or global bin
standard-version

或者你想指定發(fā)行版本號：

#指定類型 patch/minor/marjor
npm run release -- --release-as patch
#指定版本號
npm run release -- -- release-as 1.1.0

生命周期

prerelease:所有腳本執(zhí)行之前
prebump/postbump: 修改版本號之前和之后
prechangelog/postchangelog:生成 changelog 和生成 changelog 之后
pretag/postag:生成tag標(biāo)簽和之后

standard-version本身只針對本地，并沒有push才操作，我們可以在最后一步生成 tag 后，執(zhí)行 push 操作，在paceage.json中添加

"standard-version": {
    "scripts": {
      "posttag": "git push --follow-tags origin master && npm publish"
    }
  }

還有更多配置功能自行查閱官方文檔

其它類似工具

除了standard-version,還有其它類似的工具,有興趣可以去了解下

semantic-release
lerna

修改Git Commit

為了使CHANGELOG.MD更能加直觀看到每個版本的修改，我們盡量保證每次提交都是有意義的，但實際開發(fā)過程中，不可避免會提交了一些錯誤的 commit message，下面介紹幾個git命令來修改commit

1 修改最后一次提交

git commit --amend

該命令會創(chuàng)建一個提交并覆蓋上次提交，如果是因為寫錯或者不滿意上次的提交信息，使用該命令就非常適合。

2 合并多條提交

git reset --soft [commitID]

如果你想合并最近幾條提交信息的話，那么就需要使用上面的命令來操作，指定要撤銷的 ccommitId ,該命令會保留當(dāng)前改動并撤銷指定提交后的所有commit記錄，如果不指定ID的話可以使用HEAD~{num} 來選擇最近{num}條提交

git reset --soft HEAD~2 #合并最近兩條提交
git commit -m 'feat: add new feat'

帶 --soft 參數(shù)的區(qū)別在于把改動內(nèi)容添加到暫存區(qū) 相當(dāng)于執(zhí)行了git add .

git rebase -i

git rebase的功能會更加強大，如果我想修改最近3條提交記錄，執(zhí)行

git rebase -i  HEAD~3

會出現(xiàn)如下編輯器界面(vim編輯器):

上面顯示的是我最近 3條提交信息，下面是命令說明，修改方式就是將 commit 信息前的pick改為你需要的命令，然后退出:wq保存

下面是常用的命令說明：

p,pick = 使用提交
r,reword = 使用提交，但修改提交說明
e,edit = 使用提交，退出后使用git commit --amend 修改
s,squash = 使用提交，合并前一個提交
f,fixup = 和squash相同，但丟棄提交說明日志
d,drop = 刪除提交，丟棄提交記錄

最后

文本主要介紹了如何規(guī)范git commit和自動語義化版本管理，以及如何修改git commit,遵循一個規(guī)范其實沒比之前隨意填寫信息增加多少工作量，但依賴規(guī)范卻可以實現(xiàn)更多提升效率的事情。