目錄：
規范的種類
在大多數人的腦海中 Git規范 = Git Flow 或者 Git規范 = Git Flow + 提交規范。
這大概是因為從來沒有人系統、深入地理解和總結過 Git 規范相關的所有東西。
為了以后在 Git規范 方面有更清晰的表達，我這里對 Git規范 相關的概念進行重新定義下。
我把 Git 相關的規范分為了以下幾類（可能還不全，日后會慢慢完善）：
- 倉庫層級結構規范：定義了倉庫的分組（層級）結構及訪問權限。
- 協作管理規范：定義了多人協作時的管理策略。
- 分支流轉規范：定義了分支的來源、去向、合并、刪除等相關的規則。
- 合并規范：定義了合并操作的具體規則。
- 合并請求規范：定義了合并請求的步驟、信息等相關規則。
- 提交信息內容規范（簡稱提交規范）：定義了提交文件的結構、格式、信息類型等規則。
- 分支命名規范：定義了分支名字結構、格式等相關規則。
- 標簽命名規范：定義了標簽名字和信息結構、格式、信息類型等相關規則。
倉庫層級結構規范
詳情請看倉庫層級結構規范
倉庫層級結構圖
- 產品（組）：因為產品之間的關聯性較強，所以后端倉庫不一定是按產品來劃分的，但前端大多數是按產品來劃分的，所以，針對產品，需要將 前端倉庫 和 后端倉庫分開；
- 后端（組）
- 服務1（倉庫）
- 服務2（倉庫）
- 前端（組）
- 產品1（倉庫）
- 產品2（倉庫）
- 后端（組）
- 項目（組）：因為項目之間的關聯性較弱，往往有各個的前端倉庫和后端倉庫，所以默認情況可以將前端倉庫 和 后端倉庫 放在一起；如果某個項目只有前端倉庫，沒有對應的后端倉庫，那就不必為項目創建組。
- 項目1（組）
- 前端（倉庫）
- 后端（倉庫）
- 項目2（倉庫）：由于沒有后端，所以
項目2直接作為前端倉庫來創建，不必再創建成組
- 項目1（組）
- 前端工具庫（組）：用于存放封裝的庫、工具等；因為這些工具大部分是通用的，服務于開發人員的，所以本組的默認訪問權限可設為
內部 internal，特殊的組或倉庫除外；- 工具庫1（倉庫）
- 工具庫2（倉庫）
- 后端工具庫（組）：用于存放封裝的庫、工具等；因為這些工具大部分是通用的，服務于開發人員的，所以本組的默認訪問權限可設為
內部 internal，特殊的組或倉庫除外；- 工具庫1（倉庫）
- 工具庫2（倉庫）
- 運維（組）：存放一些基礎設施的項目，比如：監控系統、日志系統、腳本架工具、運維腳本等。
- 工具1（組）
- 前端（倉庫）
- 后端（倉庫）
- 工具2（倉庫）：單獨的工具，不分前后端，如：腳本等；
- 工具1（組）
倉庫目錄結構圖
訪問權限
一般情況，倉庫或組的公開性有以下幾種
- 私有
private：只有倉庫或組的成員才可以訪問； - 內部
internal：只有內部用戶（登錄的用戶）才能訪問； - 公共
public：公開的，所以有人員（登錄的 和 未登錄的）都可以訪問；
- 所有的頂層組：均為內部可見，這樣可以讓大家知道都有哪些分類，以至于在創建項目或組時在地方可以創建；
- 對于頂層組內部的組或倉庫：
- 工具庫內部的組或倉庫（內部 internal）：包括前端工具庫 和 后端工具庫
- 因為這些工具大部分是通用的，服務于開發人員的，所以本組內部的組或倉庫的默認訪問權限可設為 內部
internal，特殊的組或倉庫除外； - 如果因些工具庫的源碼不方便暴露，但文檔需要大家都能訪問，可將其文檔單獨存放在一個倉庫中，分別為源碼 和 文檔設置不同的訪問權限；
- 因為這些工具大部分是通用的，服務于開發人員的，所以本組內部的組或倉庫的默認訪問權限可設為 內部
- 產品、項目內部的組或倉庫 （私有 private）：由于 產品 和 項目 是公司重要資產，并且只需要相關人員對于源碼了解，所以這些組內部的組或倉庫的默認訪問權限應設置為 私有
private； - 運維內部的組或倉庫（私有 private）：運維相關的工具通常只有運維人員來維護，所以此組內部的組或倉庫的默認訪問權限應設為 私有
private
- 工具庫內部的組或倉庫（內部 internal）：包括前端工具庫 和 后端工具庫
一般情況下，倉庫或組的成員角色有以下幾種：
- 管理員：擁有倉庫完整的權限
- 開發者：擁有提前、推送、拉取代碼的權限
- 瀏覽者：只能查看倉庫，不能提交、推送倉庫；
- 對于公司的職員：
- 前端負責人擁有所有前端倉庫的訪問權限；
- 后端負責人擁有所有后端倉庫的訪問權限；
- 開發人員只有其所負責項目的開發者角色；
- 項目負責人擁有其所負責項目的管理員角色；
協作管理規范
我在 Git協作管理方案 中介紹多種 Git協作管理方案，不同方案有不同的適用場景，具體使用哪種方案，因項目和團隊結構而定，但對于大多數小中型項目和團隊而言，都比較適用下面2種方案：
如果這兩種方案不太理想，您可以在 Git協作管理方案 這篇文章中找到你想要的答案。
Git協作管理方案 這篇文章中講的比較抽象和通用，下面就針對 使用分支管理環境 且 支持合并請求 的項目倉庫 來具化地描述下 開測預發協作管理方案 和 穩妥型開測預發協作管理方案 的協作流程：
約定下各角色所管理的分支：
- 開發組長：開發分支
- 測試者：測試分支
- 預發布者：預發布分支
- 發布者：發布分支
當需要往這些分支上合并代碼時，都需要通過 合并請求 向對應的分支負責人申請。
因為 穩妥型開測預發協作管理方案 只是在 開測預發協作管理方案 的協作流程 上平加了 第6條，這是為了確保 開發分支 上包含了 發布分支 的全部代碼，所以可以將 開測預發協作管理方案 和 穩妥型開測預發協作管理方案 的協作流程統一描述，如下：
協作流程：
- 開發者基于
開發分支創建功能分支； - 向開發組長發起 合并請求，并在標題上添加前綴
WIP標識； - 開發者在
功能分支上做開發； - 開發組長審查代碼，對有問題的地方進行批注，并要求開發者改正；
- 當開發完畢后，相關人員在
功能分支上進行驗收； - 驗收通過后，把
開發分支上最新的變更合并進來； - 開發者自測；
- 自測試沒問題后，去除合并請求的WIP前綴，并通知開發組長處理請求；
- ??（穩妥型方案特有的步驟）開發組長將
發布分支上的新變更 合并到開發分支上。 - 開發組長確定沒問題后，同意 合并請求，并執行合并操作；
- 開發組長向測試者發起 合并請求；
- 測試者同意請求并執行合并操作；
- 測試者進行測試；
- 測試者測試通過后，向 預發布者 發起 合并請求；
- 預發布者接受請求并執行合并操作；
- 預發布者在預發布環境測試；
- 預發布環境測試通過后，預發布者向 發布者 發起 合并請求；
- 發布者接受請求并執行合并操作；
開測預發協作步驟-簡化版
分支流轉規范
目前有以下幾種分支流轉規范（關于前三者之間的區別，可看 Git 工作流程 這篇文章）：
- Git Flow：適合基于 版本發布 的項目，即：需要一段時間以后才會產出一個新版本的項目。
- GitHub Flow：適合 持續發布 的項目。
- GitLab Flow：持續發布 和 版本發布 的項目都適合，且支持多種環境。
- Git并行工作流程規范: 適合經常有很多并行功能開發的項目。
個人比較推薦 GitLab Flow 和 Git并行工作流程規范。
分支命名規范
- 使用
/作為分隔符來表達層次關系；如模塊/功能。- 相比 中劃線
-、下劃線_等其它的分隔符來說，/具有如下優勢：- 與路徑分隔符一致，從形式上更能表達出層級結構。
- 很多 git 工具會將
/解析分隔符并將分支名作為路徑來解析，然后以文件樹的形式展示分支，這樣可以更好的組織分支。
- 相比 中劃線
- 名稱中應避免冗余信息；如
模塊A/模塊A_功能A中的模塊A_功能A中的模塊A就是冗余信息。
合并規范
- 開發分支只能合并當前迭代版本的功能；
合并請求規范
- 對于需要代碼審查的分支，如果其直接下游分支是明確的，則該分支到直接下游分支的合并請求可以提前創建（比如在創建該分支時就創建到直接下游分支的合并請求），但此時合并請求的標題上應加上前綴
WIP（Work in progress 之意）標識，來表示該分支仍在開發中，當前狀態不可合并；在真正開完成時，再移除前綴WIP標識，以表示當前分支處于可合并的狀態；這樣設計的目的是：- 可讓合并請求的處理人員提前知道將來都有哪些分支需要合并；
- 合并請求的相關處理人員也可以提前做一些工作，比如：代碼審查 等，而不用等到開完成時統一檢查；在開發完成時再審查，往往審查的代碼量太多，導致審查不完成 或 不仔細；
- 分支開發人員 和 合并請求處理人員可以在分支的開發期間連續互動（通過評審、審查等），以便及時發現問題、改正問題；
- 向
測試分支、預發布分支、發布分支發起的合并請求中一定要指定里程碑和標簽； - 對于修復分支，一定要等到修復分支到母分支的合并請求合并完成之后，再繼續執行合并到開發分支的后續操作，否則容易造成將開發分支上的代碼合并到修復分支的母分支上；
- 合并請求合并完成后，要及時刪除源分支；
標簽命名規范
采用 語義化版本 規范來命名標簽。標簽的格式為：
<主版本號>.<次版本號>.<修訂號>[.<測試版本號>]
- 主版本號：當你做了不兼容的 API 修改，
- 次版本號：當你做了向下兼容的功能性新增，
- 修訂號：當你做了向下兼容的問題修正。
- 測試版本號： 當需要標明測試版本時可以在后面追加測試版本號，測試版本號可以使用測試輪數來指代。
- 先行版本號及版本編譯信息可以加到
<主版本號>.<次版本號>.<修訂號>的后面，作為延伸。
提交規范
詳見 提交規范
