溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容介紹了“Git規范操作實例分析”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
git commit message即代碼提交歷史，錯誤的提交信息會影響代碼的可維護性。在多人協作開發場景下因個人風格各有不同，若無統一的規范則很容易導致混亂。目前規范使用較多的是 Angular 團隊的規范。
每個提交消息都包含一個header、body、footer。header具備一種特殊的格式，其中包括type，scope和subject：
<type>(<scope>): <subject><BLANK LINE><body><BLANK LINE><footer>
為使在各種git工具中更易于閱讀，提交消息的任何一行都不能超過100個字符。
type
必需為以下之一開頭：
feat:一項新的功能feature
fix: bug修復
docs: 只修改了文檔
style: 沒有代碼的更改，樣式調整（空白，格式，缺少分號等）
refactor: 代碼重構，既不修正bug也不添加功能(feature)的更改
perf: 改進性能的代碼更改
test: 增加缺失或者更正現有測試
build: 影響構建系統或者外部依賴項的更改，如：gulp, broccoli, npm
ci: 對CI配置文件和腳本的更改，如：Travis，Circle，BrowserStack，SauceLabs
chore: 更改構建過程或者輔助工具和庫，例如文檔生成等
revert: 假如該提交復原了先前的提交，則應以revert:開頭 ，后接reverted commit的header。此外在body中應該標明：This reverts commit <hash>，其中hash是要復原的提交的SHA值。
scopescope是可選的。
用于輔助說明所要提交代碼更改的內容歸屬，例如可以指明是哪個位置(location)、哪個模塊(module)、哪個組件(componet)等。當更改影響的范圍不止一個范圍時，可以使用*。
subject
該主題包含對變更的簡潔形容：
使用現在時態：“change”不是“ changed”也不是“ changes”
不要大寫第一個字母
末尾沒有點（。）
就像在主題（subject）中一樣，使用命令式現在時態：“change”而不是“changed”或者“changes”。 body應包括改變的動機，并將其與以前的行為進行比照。
不兼容變動
假如當前代碼與上一個版本不兼容，則 Footer 部分以 BREAKING CHANGE 開頭,用空格或者兩個換行符，后面是對變動的形容、以及變動理由和遷移方法。如fix并攜帶BREAKING CHANGE信息：
fix: correct spelling of referrer in headerBREAKING CHANGE: Rather than using misspelled "Referer" as name of header,instead use correct spelling "Referrer". Clients expecting "Referer" will nolonger receive that header and will presumably not honor the new "Referrer"until updated to support this new name for this header.
關閉 Issue
假如當前 commit 針對某個issue，那么可以在 Footer 部分關閉這個關聯issue 。
Closes #123
或者者關閉多個issue
Closes #123 #456 #789
現在比較流行的方案是商定式提交規范（Conventional Commits），它受到了 Angular 提交原則的啟發，并在很大程度上以其為依據。筆者嘗試查找了基于非node環境相關的Git規范化的輔助工具或者插件，并沒有找到很好的處理方案，而我們假如擁有node環境非node項目也可以正常配置執行，只不過在工程中會生成node項目相關的文件，如node_modules文件夾、package.json文件等，因而在項目的版本控制中略微麻煩少量，根據需要定義自己的ingore文件，解決好項目代碼和環境代碼的問題。
node
npm(npx)
commitizen/cz-cli: 是一個格式化commit message的工具，可以束縛提交者按照制定的規范一步一步的填寫commit message。
cz-conventional-changelog: 為 commitizen 指定一個 Adapter ,一個符合 Angular 團隊規范的 preset（按照我們指定的規范幫助我們生成 commit message）
定位到workspace目錄（即項目根目錄）命令行輸入npm init，執行后會出現一系列初始化的提醒，可以一直回車至結束。
安裝commitizen和cz-conventional-changelog
npm i -D commitizen
npm i -D cz-conventional-changelog
修改package.json文件
工程的配置示例.png
{ "name": "testp", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1", "commit": "git-cz" }, "config": { "commitizen": { "path": "node_modules/cz-conventional-changelog" } }, "author": "", "license": "ISC", "devDependencies": { "commitizen": "^4.2.3", "cz-conventional-changelog": "^3.3.0" }}在項目根目錄，命令行執行npm run commit，會出現操作步驟提醒，按前文所訴填寫規范化信息。
操作提醒.png
操作提醒..png
執行完，sourcetree效果圖：
效果圖.png
盡管我們在項目中配置了commit，但是假如我執行規范操作，不使用npm run commit提交代碼，通過命令行或者者Git可視化工具直接commit，那么提交上去的可能是不規范的信息，因而需要對git命令進行阻攔，并對message內容做lint操作。
lint工具依賴安裝
commitlint/cli 【命令行工具】
commitlint/config-conventional 【校驗規則】符合 Angular團隊規范。
npm i -D @commitlint/config-conventional @commitlint/cli
修改 package.json，配置commitlint
{ ... "scripts": { "test": "echo \"Error: no test specified\" && exit 1", "commit": "git-cz", "commit-lint": "commitlint -e $HUSKY_GIT_PARAMS" }, "config": { "commitizen": { "path": "node_modules/cz-conventional-changelog" } }, "commitlint": { "extends": [ "@commitlint/config-conventional" ] }, ...}安裝Husky，進行git hooks校驗
npm install husky --save-dev
啟用git hooks
npx husky install
git hooks啟用后會在項目根目錄下生產.husky的文件夾
i
增加commit_msg到husky，用于阻攔git commit命令
npx husky add .husky/commit-msg "npm run commit-lint"
執行完成后會生成commit-msg的腳本
commit-msg-shell.png
此時我們在命令行直接執行git commit -m "test message"，會被阻攔提醒提交失敗。
image.png
通過上面配置完成后用SourceTree提交代碼會發現運行錯誤。
image.png
這是由于SourceTree沒有讀取到環境變量信息，需要在commit-msg腳本中增加環境變量的配置。
image.png
#!/bin/sh. "$(dirname "$0")/_/husky.sh"export PATH=/usr/local/bin:$PATHnpm run commit-lint --silent
此刻再運行，已成功阻攔
cz-conventional-changelog提交信息提醒和@commitlint/config-conventionallint規則都可以設置自己設置的Adapter，可以根據自己需要配置適合自己團隊的規范。
文章截圖是以非node（Android）項目的視角進行的配置，其余項目也相似，只需使用的Git進行的版本控制，都可以實現Commit Message的規范化校驗。
文章依賴的是Mac OS，Windows下相似，所有的依賴庫在Windows下也可運行工作，只不過環境的配置方式不同而已。
“Git規范操作實例分析”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
