git分支開發規範
阿新 • • 發佈:2019-01-03
轉載自:https://juejin.im/post/5b4328bbf265da0fa21a6820
您必須知道的 Git 分支開發規範
Git 是目前最流行的原始碼管理工具。 為規範開發,保持程式碼提交記錄以及 git 分支結構清晰,方便後續維護,現規範 git 的相關操作。
分支管理
分支命名
master 分支
- master 為主分支,也是用於部署生產環境的分支,確保master分支穩定性
- master 分支一般由develop以及hotfix分支合併,任何時間都不能直接修改程式碼
develop 分支
- develop 為開發分支,始終保持最新完成以及bug修復後的程式碼
- 一般開發的新功能時,feature分支都是基於develop分支下建立的
feature 分支
- 開發新功能時,以develop為基礎建立feature分支
- 分支命名: feature/ 開頭的為特性分支, 命名規則: feature/user_module、 feature/cart_module
release分支
- release 為預上線分支,釋出提測階段,會release分支程式碼為基準提測
當有一組feature開發完成,首先會合併到develop分支,進入提測時,會建立release分支。 如果測試過程中若存在bug需要修復,則直接由開發者在release分支修復並提交。 當測試完成之後,合併release分支到master和develop分支,此時master為最新程式碼,用作上線。 複製程式碼
hotfix 分支
- 分支命名: hotfix/ 開頭的為修復分支,它的命名規則與 feature 分支類似
- 線上出現緊急問題時,需要及時修復,以master分支為基線,建立hotfix分支,修復完成後,需要合併到master分支和develop分支
常見任務
增加新功能
(dev)$: git checkout -b feature/xxx # 從dev建立特性分支 (feature/xxx)$: blabla # 開發 (feature/xxx)$: git add xxx (feature/xxx)$: git commit -m 'commit comment' (dev)$: git merge feature/xxx --no-ff # 把特性分支合併到dev 複製程式碼
修復緊急bug
(master)$: git checkout -b hotfix/xxx # 從master建立hotfix分支
(hotfix/xxx)$: blabla # 開發
(hotfix/xxx)$: git add xxx
(hotfix/xxx)$: git commit -m 'commit comment'
(master)$: git merge hotfix/xxx --no-ff # 把hotfix分支合併到master,並上線到生產環境
(dev)$: git merge hotfix/xxx --no-ff # 把hotfix分支合併到dev,同步程式碼
複製程式碼
測試環境程式碼
(release)$: git merge dev --no-ff # 把dev分支合併到release,然後在測試環境拉取並測試
複製程式碼
生產環境上線
(master)$: git merge release --no-ff # 把release測試好的程式碼合併到master,運維人員操作
(master)$: git tag -a v0.1 -m '部署包版本名' #給版本命名,打Tag
複製程式碼
日誌規範
在一個團隊協作的專案中,開發人員需要經常提交一些程式碼去修復bug或者實現新的feature。而專案中的檔案和實現什麼功能、解決什麼問題都會漸漸淡忘,最後需要浪費時間去閱讀程式碼。但是好的日誌規範commit messages編寫有幫助到我們,它也反映了一個開發人員是否是良好的協作者。
編寫良好的Commit messages可以達到3個重要的目的:
- 加快review的流程
- 幫助我們編寫良好的版本釋出日誌
- 讓之後的維護者瞭解程式碼裡出現特定變化和feature被新增的原因
目前,社群有多種 Commit message 的寫法規範。來自Angular 規範是目前使用最廣的寫法,比較合理和系統化。如下圖:
Commit messages的基本語法
當前業界應用的比較廣泛的是 Angular Git Commit Guidelines
具體格式為:
<type>: <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
複製程式碼
- type: 本次 commit 的型別,諸如 bugfix docs style 等
- scope: 本次 commit 波及的範圍
- subject: 簡明扼要的闡述下本次 commit 的主旨,在原文中特意強調了幾點 1. 使用祈使句,是不是很熟悉又陌生的一個詞,來傳送門在此 祈使句 2. 首字母不要大寫 3. 結尾無需新增標點
- body: 同樣使用祈使句,在主體內容中我們需要把本次 commit 詳細的描述一下,比如此次變更的動機,如需換行,則使用 |
- footer: 描述下與之關聯的 issue 或 break change,詳見案例
Type的類別說明:
- feat: 新增新特性
- fix: 修復bug
- docs: 僅僅修改了文件
- style: 僅僅修改了空格、格式縮排、都好等等,不改變程式碼邏輯
- refactor: 程式碼重構,沒有加新功能或者修復bug
- perf: 增加程式碼進行效能測試
- test: 增加測試用例
- chore: 改變構建流程、或者增加依賴庫、工具等