Git 分支開發規範

image

 

分支管理

分支命名

master 分支html

  • master 爲主分支,也是用於部署生產環境的分支,確保master分支穩定性
  • master 分支通常由develop以及hotfix分支合併,任什麼時候間都不能直接修改代碼

develop 分支git

  • develop 爲開發分支,始終保持最新完成以及bug修復後的代碼
  • 通常開發的新功能時,feature分支都是基於develop分支下建立的

feature 分支github

  • 開發新功能時,以develop爲基礎建立feature分支
  • 分支命名: feature/ 開頭的爲特性分支, 命名規則: feature/user_module、 feature/cart_module

release分支web

  • release 爲預上線分支,發佈提測階段,會release分支代碼爲基準提測
當有一組feature開發完成,首先會合併到develop分支,進入提測時,會建立release分支。
若是測試過程當中若存在bug須要修復,則直接由開發者在release分支修復並提交。
當測試完成以後,合併release分支到master和develop分支,此時master爲最新代碼,用做上線。
複製代碼

hotfix 分支segmentfault

  • 分支命名: hotfix/ 開頭的爲修復分支,它的命名規則與 feature 分支相似
  • 線上出現緊急問題時,須要及時修復,以master分支爲基線,建立hotfix分支,修復完成後,須要合併到master分支和develop分支

常見任務

增長新功能bash

(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,同步代碼 複製代碼

測試環境代碼ide

(release)$: git merge dev --no-ff             # 把dev分支合併到release,而後在測試環境拉取並測試 複製代碼

生產環境上線工具

(master)$: git merge testing --no-ff          # 把testing測試好的代碼合併到master,運維人員操做 (master)$: git tag -a v0.1 -m '部署包版本名' #給版本命名,打Tag 複製代碼

 

image

 

日誌規範

在一個團隊協做的項目中,開發人員須要常常提交一些代碼去修復bug或者實現新的feature。而項目中的文件和實現什麼功能、解決什麼問題都會漸漸淡忘,最後須要浪費時間去閱讀代碼。可是好的日誌規範commit messages編寫有幫助到咱們,它也反映了一個開發人員是不是良好的協做者。post

編寫良好的Commit messages能夠達到3個重要的目的:

  • 加快review的流程
  • 幫助咱們編寫良好的版本發佈日誌
  • 讓以後的維護者瞭解代碼裏出現特定變化和feature被添加的緣由

目前,社區有多種 Commit message 的寫法規範。來自Angular 規範是目前使用最廣的寫法,比較合理和系統化。以下圖:

image

 

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: 改變構建流程、或者增長依賴庫、工具等

Commit messages格式要求

# 標題行:50個字符之內,描述主要變動內容 # # 主體內容:更詳細的說明文本,建議72個字符之內。 須要描述的信息包括: # # * 爲何這個變動是必須的? 它多是用來修復一個bug,增長一個feature,提高性能、可靠性、穩定性等等 # * 他如何解決這個問題? 具體描述解決問題的步驟 # * 是否存在反作用、風險? # # 若是須要的化能夠添加一個連接到issue地址或者其它文檔 複製代碼

參考連接

 


做者:VincentSea
連接:https://juejin.im/post/5b4328bbf265da0fa21a6820
來源:掘金
著做權歸做者全部。商業轉載請聯繫做者得到受權,非商業轉載請註明出處。

 

 

 

 

 

 

 

 

 

 

 

Git 分支命名規範
分支: 命名: 說明:

主分支 master 主分支,全部提供給用戶使用的正式版本,都在這個主分支上發佈
開發分支 dev 開發分支,永遠是功能最新最全的分支
功能分支 feature-* 新功能分支,某個功能點正在開發階段
發佈版本 release-* 發佈按期要上線的功能
修復分支 bug-* 修復線上代碼的 bug

主分支 Master
首先,代碼庫應該有一個、且僅有一個主分支。全部提供給用戶使用的正式版本,都在這個主分支上發佈。

Git主分支的名字,默認叫作 Master 。它是自動創建的,版本庫初始化之後,默認就是在主分支在進行開發。

開發分支 Dev
主分支只用來分佈重大版本,平常開發應該在另外一條分支上完成。咱們把開發用的分支,叫作 Dev
這個分支能夠用來生成代碼的最新隔夜版本(nightly)。若是想正式對外發布,就在 Master 分支上,對 Dev 分支進行」合併」(merge)。

Git建立 Dev 分支的命令:

git checkout -b dev master

將 Dev 分支發佈到 Master 分支的命令:
切換到 Master 分支
git checkout master

對 Dev 分支進行合併
git merge –no–ff dev

這裏稍微解釋一下,上一條命令的–no–ff參數是什麼意思。默認狀況下,Git執行」快進式合併」(fast-farward merge),會直接將 Master 分支指向 Dev 分支。
使用–no–ff參數後,會執行正常合併,在 Master 分支上生成一個新節點。爲了保證版本演進的清晰,咱們但願採用這種作法。

功能分支 Feature
功能分支的名字,能夠採用feature- * 的形式命名。

建立一個功能分支:

git checkout -b feature-x dev

開發完成後,將功能分支合併到dev 分支:
git checkout dev
git merge –no-ff feature-x

刪除feature分支:
git branch -d feature-x

預發佈分支 Release
第二種是預發佈分支,它是指發佈正式版本以前(即合併到 Master 分支以前),咱們可能須要有一個預發佈的版本進行測試。
預發佈分支是從 Dev 分支上面分出來的,預發佈結束之後,必須合併進 Dev 和 Master 分支。它的命名,能夠採用release- * 的形式。

建立一個預發佈分支:

git checkout -b release-1.2 dev

確認沒有問題後,合併到master分支:
git checkout master
git merge –no-ff release-1.2

對合並生成的新節點,作一個標籤:
git tag -a 1.2

再合併到dev 分支:
git checkout dev
git merge –no-ff release-1.2

最後,刪除預發佈分支:
git branch -d release-1.2

修補分支 Bug
最後一種是修補bug分支。軟件正式發佈之後,不免會出現bug。這時就須要建立一個分支,進行bug修補。
修補bug分支是從 Master 分支上面分出來的。修補結束之後,再合併進 Master 和 Dev 分支。它的命名,能夠採用fixbug- * 的形式。

建立一個修補bug分支:

git checkout -b fixbug-0.1 master

修補結束後,合併到master分支:
git checkout master
git merge –no-ff fixbug-0.1
git tag -a 0.1.1

再合併到dev 分支:
git checkout dev
git merge –no-ff fixbug-0.1

最後,刪除」修補bug分支」:
git branch -d fixbug-0.1

git tag usage# 添加git tag -a V0.1.110811 -m"基本部署完成,有BUG待作" #刪除git tag -d V0.1.110811 #推送到遠程git push origin V0.1.110811 git push –tags

相關文章
相關標籤/搜索