產品管理開發之Git工做流和分支規範推薦

前言

不管是開源項目仍是內部項目，使用Git都是大勢所趨，尤爲是在產品管理這塊，使用Git大大提升了開發效率和產品的交付頻率。本篇，針對Git的工做流和分支使用，進行了一些推薦。

 

目錄

1     產品管理開發之Git工做流和分支規範推薦

1.1      Git工做流模型推薦

1.2      Git產品開發分支規範要求

1.2.1      永久分支

1.2.1.1  master（穩定版）

1.2.1.2   開發版（develop）

1.2.2      臨時性分支

1.2.2.1   功能（feature）分支

1.2.2.2   預發佈（release）分支

1.2.2.3   修補bug（hotfix）分支

1.2.3      代碼分支提交使用規範

 

 

1 產品管理開發之Git工做流和分支規範推薦

不管是開源項目仍是內部項目，使用Git都是大勢所趨。所以，針對Git的工做流和分支使用，本篇進行了一些推薦：

 

1.1   Git工做流模型推薦

 

1.2   Git產品開發分支規範要求

在產品開發或者複雜項目開發，咱們推薦嚴格遵循此規範進行開發。對於中小項目和我的開發，您能夠按需來設計本身的規範和要求。

 

1.2.1    永久分支

1.2.1.1    master（穩定版）

主分支，主分支只用來發布重大版本。全部提供給用戶使用的正式版本，都在這個主分支上發佈。

 

1.2.1.2    開發版（develop）

平常開發應該基於此分支來完成。

若是想正式對外發布，就在Master分支上，對Develop分支進行"合併"（merge）。

 

1.2.2    臨時性分支

除了永久分支之外，還有一些臨時性分支，用於應對一些特定目的的版本開發。臨時性分支主要有三種：

• 功能（feature）分支

• 預發佈（release）分支

• 修補bug（hotfix）分支

這三種分支都屬於臨時性須要，使用完之後，應該刪除，使得代碼庫的常設分支始終只有Master和Develop。

 

1.2.2.1    功能（feature）分支

功能分支，它是爲了開發某種特定功能，從Develop分支上面分出來的。開發完成後，要再併入Develop。

功能分支的名字，請採用feature/feature1  的形式命名。

 

1.2.2.2    預發佈（release）分支

預發佈分支，它是指發佈正式版本以前（即合併到Master分支以前），咱們可能須要有一個預發佈的版本進行測試。

預發佈分支是從Develop分支上面分出來的，預發佈結束之後，必須合併進Develop和Master分支。它的命名，請採用release/release1的形式。

 

1.2.2.3    修補bug（hotfix）分支

修補bug分支。軟件正式發佈之後，不免會出現bug。這時就須要建立一個分支，進行bug修補。

修補bug分支是從Master分支上面分出來的。修補結束之後，再合併進Master和Develop分支。它的命名，請採用hotfix/fixbug1的形式。

 

 

1.2.3    代碼分支提交使用規範

• 使用Git過程當中，必須經過建立分支進行開發，堅定禁止在主幹分支上直接開發。review的同事有責任檢查其餘同事是否遵循分支規範。

• 在Git中，默認是不會提交空目錄的，若是想提交某個空目錄到版本庫中，須要在該目錄下新建一個.gitignore 的空白文件，就能夠提交了

• 把外部文件歸入到本身的Git 分支來的時候必定要記得是先比對，確認全部修改都是本身修改的，而後再歸入。

• 提交時，必定要填寫有意義的註釋。註釋內容要求以下：第一行爲提要，而後逐行羅列出功能點、主要變更、以及須要注意的問題等等。具體以下所示：

 

註釋提交模板：

簡要說明（第一行）

（空行）

1. （要點）

2. （要點）

 

註釋提交參考：

1. 後臺菜單管理增長區域菜單功能，修復日誌記錄器若干問題

2. 後臺菜單管理增長區域菜單功能，目前分爲系統平臺和租戶平臺，根據屬性MenuPlatform來設置增長若干系統管理菜單

3. 完善菜單模塊，以便加載不一樣平臺菜單

4. 修復日誌記錄器爲NULL的情形