从0到1开发实战手机站(二):Git提交规范配置
生活不能隨意過,代碼也不能隨意寫。
前一篇文章我們已經把項目搭建好了,那是不是馬上就開始寫頁面了呀?
NO!
無論在哪家公司,都會有相應的代碼規范。新入職的員工往往第一步就要接受代碼規范的學習。
既然是實戰項目,我們也得在寫頁面之前把相關的規范配置做好。
今天我們先來看看項目中git的使用及相關規范吧。
Git規范及項目配置
目的
版本規范
1.分支
- master: 主分支(保護分支),不能直接在master上進行修改代碼和提交;
- develop: 測試分支,所以開發完成需要提交測試的功能合并到該分支;
- feature-*: 新功能開發分支,根據不同需求創建獨立的功能分支,開發完成后合并到develop分支;
- hotfix-*: bug修復分支,根據實際情況對已發布的版本進行漏洞修復;
- release-*: 預發布分支。
2.Tag
采用三段式,v版本.里程碑.序號,如v1.2.3
- 架構升級或架構重大調整,修改第1位
- 新功能上線或者模塊大的調整,修改第2位
- bug修復上線,修改第3位
3.changelog
版本正式發布后,需要生產changelog文檔,便于后續問題追溯。
提交規范
Git commit日志基本規范
每次提交,Commit message 都包括三個部分:Header,Body 和 Footer。
<type>(<scope>): <subject> // 空一行 <body> // 空一行 <footer> 復制代碼注意冒號后面有空格。
其中,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個字符。 其他注意事項:
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來執行規范
mac下需在前面加sudo
配好后,之后用到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 的工具.
運行下面的命令即可:
這時你會發現項目目錄里面多了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效驗提交信息
@vue/cli-service 也會安裝 yorkie,但yorkie fork 自 husky 且并不和之后的版本兼容。所以這里我還是安裝了husky
這樣就配好了,現在我們來測試一下:
上圖可以看到,當我type輸錯時會報錯,這樣我們就不怕不小心打錯自己沒注意到的情況啦。
修改之后成功提交。
合并提交
最后我們把我們今天的工作提交到github上吧
git checkout develop git merge feature-git代碼提交信息審查 git checkout master git merge develop git push 復制代碼小結
今天花了較大篇幅講解如何為何配置GIT提交規范及如何配置,實在是小肆深知在實際工作過程中遵守規范是多么重要的一件事.
尤其是團隊開發或是開源項目,可以說一個程序員的代碼素質從他的每一次提交記錄就能體現一二,所以還望大家能重視起來。
接下來幾篇小肆會為大家帶來代碼效驗、自動格式化、手機端適配、判斷訪問客戶端類型等前期準備工作,關注我的公眾號"技術放肆聊"持續關注吧!
前置閱讀:
總結
以上是生活随笔為你收集整理的从0到1开发实战手机站(二):Git提交规范配置的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 免费的源代码编辑器Notepad++ 7
- 下一篇: 第六届北京八大处新春祈福庙会大年初一迎客