前端 Git 使用约定
前端 Git 使用約定
背景
開發前端項目,有以下困惑:
- 使用哪個分支開發,哪個分支發布
- 修復線上bug的流程是什么,如何避免修復完了下次卻又出現了
- cms分支有十多個,是否都有用
- 如何快速找到之前某次功能開發,或某次bug修復
為了減輕上述困擾,引入 gitflow 規范,并根據公司情況做適當調整。
gitflow
GitFlow 是一種基于 Git 的工作流程設計,它是由 Vincent Driessen 在2010年提出的。是一種分支管理模型。請看下圖:
從右往左一共5個分支。
首先是 master 主分支,也就是線上代碼。不應該直接修改,只需要合并其他分支。
其次是 develop 開發分支,從master拉取,也不應該直接修改。
現在有兩個版本的需求需要開發,一個是下一個版本 1.0 的(Major feature for next release)的需求,另一個是下下個版本2.0(Feautre for future release)的需求,時間更長。所以直接從 develop 分支拉取兩個 feature 功能分支。
其他人也在持續的推進 develop 分支的前進
現在 1.0 的需求開發完成,于是將 feature 分支合并到 develop 中,然后從 develop 中拉取一個 release 分支,用于發布前的測試,這個 release 分支就不在開發新功能,只做bug修復(Only bugfixes),同時修復的bug也需要同步到 develop 分支,最后測試通過,則將 release 分支合并到 master 分支,同時將 release 分支合并到 develop。
線上有了問題,需要緊急處理,于是從 master 拉取 hotfixes 分支,修復完成后將 hotfixes 合并到 master 分支和 develop 分支,避免后續 develop 還有這個問題。
其中 master 分支和 develop 分支是一直存在的,其他分支都是臨時的。master 分支用于存放穩定的生產版本代碼,而 develop 分支則用于集成各個功能分支最新的開發成果。
分支和環境對應關系:
| feature | develop | release | hotfix | master |
|---|---|---|---|---|
| 開發環境 | 測試環境 | 預發布環境 | 線上 | 線上 |
分支流程:
feature -> develop -> release -> master
小建議
- 保持 develop 分支和 feature 分支同步:如果 develop 變動比較頻繁,建議每天上班就將 develop 分支合并到 feature,這樣避免兩個分支差別太大,造成 feature 不能合并到 develop分支,或者需要很長時間解決沖突。
- feature 分支也要時刻提交代碼。萬一機器壞了...
提交信息規范
Conventional Commits 是一種提交消息的規范格式
<類型>[可選的作用域]: <描述>
[可選的正文]
[可選的腳注]
例如:
/*
<類型>[可選的作用域]: <描述>
*/
feat(login): add login form validation
/*
<類型>[可選的作用域]: <描述>
[可選的正文]
*/
fix(注冊): 修復用戶注冊時的驗證邏輯錯誤
之前的邏輯判斷漏掉了對用戶名長度的限制,導致用戶可以注冊過長的用戶名,現在已經修復了該問題,并增加了相應的驗證邏輯。
修復了一個潛在的安全漏洞。
/*
<類型>[可選的作用域]: <描述>
[可選的正文]
[可選的腳注]
*/
feat(auth): 增加JWT認證
- 實現 JWT 生成和驗證
- 更新認證中間件
關閉問題 #12345
類型有如下:
-
feat:表示引入新的功能(feature)的提交,即添加新的功能特性。 -
fix:表示修復 bug 的提交,用于修正代碼中的錯誤或問題。 -
docs:表示文檔變更的提交,指示與文檔相關的修改,比如更新文檔或注釋。 -
style:表示代碼樣式(style)的修改,通常是不影響代碼含義的調整,比如空格、格式化等。 -
refactor:表示重構代碼的提交,即對現有代碼結構進行非修復性的修改。 -
test:表示增加或修改測試的提交,用來新增或調整單元測試、集成測試等測試代碼。 -
chore:表示其他零碎的提交,通常包括構建工具、輔助工具等的修改,比如更新構建腳本、任務管理等。 -
perf: 性能提升
示例如下:
feat: 添加用戶管理模塊
fix: 修復用戶登錄時的密碼驗證問題
docs: 更新安裝指南
style: 格式化用戶信息顯示界面
refactor: 重構用戶信息存儲邏輯
test: 添加用戶注冊模塊的單元測試
CMS改造
以CMS為例,常用的分支需要三種:開發分支、預發布分支、master分支。將其重命名并與jenkins同步。具體操作如下:
CMS目前有 4 個分支:
PS ChinaEdu-H5> git branch -r
origin/HEAD -> origin/cms_master
origin/test2
origin/cms_master
origin/cms_pre
origin/cms_test
將分支重命名,分支和環境的對應關系如下:
// 將 test2 分支重命名 develop,對應測試環境
test2 -> develop 對應測試環境
cms_pre -> release 對應預發布環境
cms_master -> master 對應線上環境
例如將 test2 重命名為 develop:
$ /cms (test2)
$ git pull
Already up to date.
$ /cms (test2)
$ git branch -m test2 develop
$ /cms (develop)
$ git push -u origin :test2 develop
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote:
remote: To create a merge request for develop, visit:
remote: https://gitlab.xx.com/cms-ui/...
remote:
To https://gitlab.xx.com/cms-ui.git
- [deleted] test2
* [new branch] develop -> develop
Branch 'develop' set up to track remote branch 'develop' from 'origin'.
另外兩個分支也類似。
修改 jenkins 的配置:
- cms-test-pipeline-ui 構建的分支從 test2 改為 develop
- cms-master-pipeline-ui 構建的分支為 從 cms_pre 改為 release
修改分支下的Jenkinsfile文件:
- 修改 develop 分支中 Jenkinsfile 中的
def GIT_BRANCH = "develop" - 修改 release 分支中 Jenkinsfile 中的
def GIT_BRANCH = "release"
Tip:由于每個分支下的 cicd 中的內容可能不同,這里使用 .gitattributes。比如有一個文件 Dockerfile,在兩個分支中它是不同的,合并時不想弄亂,可以這么做:
- 在根目錄下創建 .gitattibutes 文件,并設置內容
Dockerfile merge=ours - 設置git merge的配置項
git config --global merge.ours.driver true
當你合并其他分支時,如果生效,在命令行中會顯示:
$ git checkout branchA
$ git merge branchB
Auto-merging Dockerfile
Merge made by recursive.
Tip:需要注意的是,gitattribute 方法生效是有條件的,跟文件的修改時間順序有關系。比如在 pre 分支中合并 develop,如果不想 pre 分支中 Dockerfile 被覆蓋,需要 pre 中的 Dockerfile 更新,也就是要比 develop 中的 Dockerfile 修改時間更加接近現在。
Q/A
問:使用哪個分支開發,哪個分支發布
答:從 develop 分支拉取 feature 分支進行開發,用 release 分支預發布,用 master 發布。
問:修復線上bug的流程是什么,如何避免修復完了下次卻又出現了
答:直接從master分支拉取 hotfixes 分支開發,然后合并到 develop 分支到測試環境測試,如果緊急則直接合并到 release,在預發布測試通過后合并到 master,最后不要忘記合并到 develop
問:cms分支有十多個,是否都有用
答:沒有用的分支盡快刪除
問:如何快速找到之前某次功能開發,或某次bug修復
答:使用Conventional Commits提交規范
問:dist 需要提交嗎?
答:不需要,jenkins 會自己構建。
總結
以上是生活随笔為你收集整理的前端 Git 使用约定的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: OpenGL纹理转换谜团:纹理写入FRA
- 下一篇: iOS开发--绘图教程