前言
無論是開源項目還是內部項目，使用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 分支來的時候一定要記得是先比對，確認所有修改都是自己修改的，然后再納入。
提交時，一定要填寫有意義的注釋。注釋內容要求如下：第一行為提要，然后逐行羅列出功能點、主要變動、以及需要注意的問題等等。具體如下所示：
注釋提交模板：
簡要說明（第一行）
（空行）
（要點）
（要點）
注釋提交參考：
后臺菜單管理增加區域菜單功能，修復日志記錄器若干問題
后臺菜單管理增加區域菜單功能，目前分為系統平臺和租戶平臺，根據屬性MenuPlatform來設置增加若干系統管理菜單
完善菜單模塊，以便加載不同平臺菜單
修復日志記錄器為NULL的情形
