帶你360度玩轉項目工程化(二):實現規範化Git提交流程

時間 2020-04-26

標籤項目工程實現規範化 git 提交流程欄目 Git 简体版

原文原文鏈接

如何實現規範化Git提交流程

通常來講，項目代碼經過Git倉庫進行管理，提交流程通常以下：git

git pull --> git commit --> git pushgithub

因爲大部分公司項目都是以項目組形式進行開發維護，基於GitFlow進行分支流程管理的前提下，雖然對版本進行了規範，可是從版本的管理維護的層面上，根據對項目成員每次提交的commit message進行分析，目前大部分的項目提交信息都是比較粗糙模糊，不知道此次提交具體是修復 bug 呢？仍是增長新功能，仍是單純改了一些配置文件，亦或是重構了一些很差的代碼。只能靠你們本身去猜想，就算是本身提交的信息，也可能由於時間長致使本身也不清楚具體此次提交是爲了幹什麼，只能去提交記錄裏翻代碼，久而久之，不利於產品的迭代，以及對於 bug 的定位。所以對commit message 規範化在項目的維護上是必須的。npm

具體git commit message 規範：

<type>(<scope>): <subject>

<BLANK LINE>

<body>

<BLANK LINE>

<footer>
複製代碼

type(必需) ： Type of change：commit的類別；json

scope(可選)：Scope of this change：這次commit的影響模塊；bash

subject(必需)：Short description：簡短的描述這次代碼變動的主要內容maven

Header

1）typeide

type用於說明commit的類別，經常使用的標識以下：工具

標識名稱	解釋
feat	新功能（feature）
fix	修補bug
docs	文檔（documentation）
style	格式（不影響代碼運行的變更,空格,格式化,等等）
refactor	重構（即不是新增功能，也不是修改bug的代碼變更
perf	性能 (提升代碼性能的改變)
test	增長測試或者修改測試
build	影響構建系統或外部依賴項的更改(maven,gradle,npm 等等)
ci	對CI配置文件和腳本的更改
chore	對非 src 和 test 目錄的修改
revert

（2）scope性能

scope用於說明 commit 影響的範圍，好比數據層、控制層、視圖層等等，視項目不一樣而不一樣。開發工具

（3）subject

subject是 commit 目的的簡短描述，不超過50個字符，主要介紹這次代碼變動的主要內容。

舉個例子：

eg: feat(訂單模塊)：訂單詳情接口增長訂單號字段

其中， feat對應type字段；訂單模塊對應scope(若果scope有內容，括號就存在)；「訂單詳情接口增長訂單號字段」對應subject，簡要說明這次代碼變動的主要內容。

Body

Body 部分是對本次 commit 的詳細描述，能夠分紅多行。

如：

（1）增長訂單號字段；

（2）增長了訂單退款接口；

平常項目開發中，若是Header中subject已經描述清楚這次代碼變動的內容後，Body部分就能夠爲空。

Footer

（1）不兼容變更

（2）關閉 Issue

平常項目中開發，Footer不經常使用，可爲空。

Revert

若須要撤銷上一次的commit，header部分爲：revert: 上一次commit的header內容；

body部分爲：This reverts commit xxx，xxx是上一次commit對應的SHA 標識符。

Git commit message 插件介紹

寫在紙上/文檔上的規範不如讓規範走進開發、貼近開發，利用開發工具去規範是開發者最容易接受、甚至是最欣然接受的方式，畢竟用得爽還沒什麼成本。

實現commit message 規範化的方式上，通過分析試用**，IDEA 」Git Commit Message「插件與VSCODE 」git-commit-plugin「插件**可以爲規範化commit message提供良好的支持。

接下來以 IDEA 」Git Commit Message「插件使用進行體驗介紹

1.commit 代碼,彈出commit對話框

2.按照模板填寫提交信息，點擊OK

3.生成commit message

\[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-s3Lc3fqt-1587818803124)(C:\Users\lps\Documents\myblog\idea\git管理.assets\image-20200425180759192.png)\]

自動生成CHANGELOG.md

CHANGELOG.md是用於維護項目每一個版本迭代升級的文件，Git版本管理並不只僅是單向的Git代碼提交，不斷地commit，不斷地迭代版本，還須要每一個版本歷史更新/解決的內容的維護，便於回溯與管理，而CHANGELOG.md的存在，是向團隊開發者、項目管理者、需求等人員對項目每一個版本具體更新內容清晰地瞭解，能追溯到版本commit對應的issue解決，便於找到對應責任chain。

例子以下：

項目開發者、項目管理者以及需求能夠經過CHANGELOG.md查看每一個版本改動的內容以及對應修復的bug。

怎麼寫 CHANGELOG.md？

因爲大部分開發人員對寫文檔這些都有那麼一絲絲的排斥，以下：

一個版本那麼多issue,那麼多commit，我很難辦阿！

針對此情況，富強表示，CHANGELOG.md文件是能夠根據咱們通過規範化的commit message 生成的，生成後能夠繼續進行手動修改後，再提交。

使用standard-version自動生成CHANGELOG.md

standard-version 是一款遵循語義化版本（ semver）和 commit message 標準規範的版本和 changlog 自動化工具。一般狀況下，咱們在一個版本主要是release版本發佈後咱們會在 master 分支進行以下的版本發佈操做：

git pull origin master
根據 pacakage.json 中的 version 更新版本號，更新 changelog
git add -A, 而後 git commit
git tag 打版本操做
push 版本 tag 和 master 分支到倉庫

(1) 安裝

本地輸入如下命令進行全局安裝

npm install -g standard-version
複製代碼

(2) 使用

推薦用法：在package.json定義命令以下：

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

(3) 運行結果

在項目目錄運行

npm run release 
複製代碼

便可生成CHANGELOG(每次疊加)

生成例子：

\# Change Log

 

All notable changes to this project will be documented in this file. See [standard-version](https://github.com/conventional-changelog/standard-version) for commit guidelines.

 

<a name="1.0.4"></a>

\## 1.0.4 (2020-04-17)

  

<a name="1.0.3"></a>

\## 1.0.3 (2020-04-17)

 

\### Features

 \* **lint:** 添加1功能 ([faee26d](http://url/commits/faee26d))

\* **lint:** 簡化2配置 ([affeb7d](http://url/commits/affeb7d))
複製代碼