git commit 規範

本文主要羅列一些node

我在使用 git 時候的問題webpack
git 的常見命令git

一方面作個排坑的梳理一方面也方便本身之後查詢這些命令github

排坑

git pull / push 卡住

git pull / push卡住的可能性有不少web

發生這種問題通常是訪問不了 githubnpm

這裏能夠登陸 ipaddress.com 查看 github.com 的 ip 而後修改 host 能夠藉助 switchHosts 快速修改 hostsjson

gitee 圖牀

由於 gitee 國內速度比 github 快因此博主使用 gitee 做爲本身的圖牀跨域

可是某一次在使用的時候卻發現了跨域問題？？？？？性能優化

排查以後發現是由於圖片大於 1M gitee 就須要登陸校驗身份因此圖片須要小於 1Mbash

經常使用命令

描述	命令
快速切換到上一個分支	git checkout -
撤銷當前分支的全部修改	git checkout .
拉取遠程分支	git checkout -b [localbranch]/[remote] [branch]
查看全部遠程分支	git branch -a
刪除遠程分支	git push origin --delete [branch]
強制刪除分支	git branch -D [branch]
將 dev 分支和當前分支合併	git merge dev
查看暫存區的文件	git ls-files
刪除暫存區裏的文件	git rm --cached [file]
本地分支關聯遠程分支	git branch --set-upstream-to [remote]/[branch] [localbranch]
回退版本	git reset --hard [id]

git commit 規範

良好的 git commit 不只有良好的可讀性並且有利於生成 change logs 作一些自動化的事情

例如 angular.js 的官網 github.com/angular/ang…

在這裏 git commit 就很是清晰不一樣的 commit 分紅了不一樣的類型讓人一眼就知道此次 commit 對應幹了什麼

commit 的規範網上有不少介紹這裏只說一點

Commit message 都包括三個部分：header，body 和 footer

Header
- type （必需） commit 的類別
- scope 影響的範圍
- subject（必需）簡短的說明
Body 詳細的說明
Footer

type 的類型	描述
feat	新增功能
fix	bug 的修復
perf	性能優化
refactor	重構代碼(既沒有新增功能，也沒有修復 bug)
build	主要目的是修改項目構建系統(例如 glup，webpack，rollup 的配置等)的提交
ci	主要目的是修改項目繼續集成流程(例如 Travis，Jenkins，GitLab CI，Circle 等)的提交
docs	文檔更新
style	不影響程序邏輯的代碼修改(修改空白字符，補全缺失的分號等)
revert	回滾某個更早以前的提交
chore	變動構建流程和輔助工具
test	新增測試用例或是更新現有測試

每一個提交都必須使用類型字段前綴，它由一個名詞組成，諸如 feat 或 fix，其後接一個可選的做用域字段，以及一個必要的冒號（英文半角）和空格。
當一個提交爲應用或類庫實現了新特性時，必須使用 feat 類型。
當一個提交爲應用修復 bug 時，必須使用 fix 類型。
做用域字段能夠跟隨在類型字段後面。做用有必須是一個描述某部分代碼的名詞，並用圓括號包圍，例如：fix(parser):
描述字段必須緊接在類型/做用域前綴的空格以後。描述指的是對代碼變動的簡短總結，例如：fix:array parsing issue when multiplejspaces were contained in string。
在簡短描述以後，能夠編寫更長的提交正文，爲代碼變動提供額外的上下文信息。正文必須起始於描述字段結束的一個空行後。
在正文結束的一個空行以後，能夠編寫一行或或多行腳註。腳註必須包含關於提交的元信息，例如：關聯的合併請求、Reviewer、破壞性變動、每條元信息一行。
破壞性變動必須標示在正文區域最開始處，或腳註區域中某一行的開始。一個破壞性變動必須包含大寫的文本 BREAKING CHANGE，後面緊跟冒號和空格。
在 BREAKING CHANGE:以後必須提供描述，以描述對 API 的變動。例如：BREAKING CHANGE: enviroment variables now take precedence over cofig files。
在提交說明中，可使用 feat 和 fix 以外的類型。
工具的實現必須不區分大小寫地解析構成約定式提交的信息單元，只有 BREAKING CHANGE 必須是大寫的。
能夠在類型/做用域前綴以後，:以前，附加!字符，以進一步提醒注意破壞性變動。當有!前綴時，正文或腳註內必須包含 BREAKING CHANGE: description

這裏主要的話仍是推薦一款插件去幫助咱們規範本身的 commit 就是 husky

一、Git Commit 檢測工具鏈

yarn add -D husky @commitlint/config-conventional @commitlint/cli
複製代碼

配置 husky 插件（在 package.json 中新增一個 husky 相關配置）

"husky": {
  "hooks": {
    "pre-commit": "npm run lint", // 不須要在Commit時lint，不配置此項
    "commit-msg": "commitlint -E HUSKY_GIT_PARAMS" // 提交信息檢測
  }
}
複製代碼

在項目的根目錄下新建一個 commitlint.config.js 文件

Husky 配置

module.exports = {
  extends: ['@commitlint/config-conventional'], // 使用@commitlint/config-conventional規範
};
複製代碼

以上配置完畢後，若是不按照規範提交是沒法提交的。

husky 工具會直接從 Git 命令層面打斷你的提交。

請按照規範進行提交

二、輔助 Git Commit 提交格式化的的工具

輔助提交工具

yarn add -D commitizen // 本地安裝

npm install -g commitizen // 全局安裝，全局安裝後可使用 git cz 命令，運行git cz 會幫助咱們打開交互式的提交
複製代碼

本地項目 commitizen 配置（在 package.json 中）

cz 命令配置

"scripts": {
  "cz": "git-cz",
},
"config": {
  "commitizen": {
      "path": "./node_modules/cz-conventional-changelog" // 這個文件是commitizen的內部依賴，裏面定義了符合Angular提交規範的相關信息，也會方便咱們後續生成changelog.md的日誌
    }
}
複製代碼

以上配置完畢後，就可使用 git cz(全局) 或者 npm run cz/yarn cz 幫助咱們進行提交了

三、日誌生成與版本號自動控制工具（項目管理者使用，成員瞭解便可）

changelog

yarn add -D standard-version

在package.json 中的配置

"scripts": {
    "major": "standard-version -r major", // 一個最大的版本升級, 會生成相關的changelog,修改版本號 1.0.0 -> 2.0.0，生成一個Tag
    "minor": "standard-version -r minor", // 中等的版本升級 會生成相關的changelog,修改版本號 1.0.0 -> 1.1.0, 生成一個Tag
    "patch": "standard-version -r patch --skip.tag",// 最小的版本升級 會生成相關的changelog,修改版本號 1.0.0 -> 1.0.1, 跳過生成Tag.
    "init": "standard-version  --first-release --skip.tag" // 首次生成相關的changelog, 不修改版本號, 跳過生成Tag. // 也能夠不配置進腳本，用npx standard-version  --first-release --skip.tag 執行
  },
複製代碼