作為廣為流傳的 Git Flow 的原圖所體現的信息并不完整，比如：缺少測試分支、發布分支的bug修復分支、預發布分支等等。為了準確、充分、形像、清晰地表達 Git Flow 中的 分支流轉規則，我新定義了一些相關概念，并重新嚴格地描述了 Git Flow，也為其重新設計并繪制了一張 分支流轉規范圖，詳情如下：

下文描述中使用了一些新的概念，相關概念的定義請看 分支相關的概念

各種分支的流轉規則如下：

• 發布分支：該分支從 預發布分支 合并而來；如果沒有 預發布分支，則從 測試分支 合并而來；
• 預發布分支：該分支從 測試分支 合并而來；如果不需要，也可以不設 預發布分支；
• 測試分支：該分支從 開發分支 或 測試修復分支 合并而來；
• 開發分支：用于協作開發的主干分支。
  • 其它分支在合并到開發分支前，需要確保 被合并的分支 已經包含了開發分支上的所有版本；即：如果被合并的分支在合并前，開發分支上有新的變更，且這些新的變更并沒有包含在 被合并的分支上，則需要先把開發分支上那些新的變更合并到被合并分支上，確保沒問題后，然后才能再將分支合并到開發分支上；
  • 因為 開發分支 會被頻繁使用到，所以建議將開發分支設置成倉庫的默認分支；
• 功能分支：基于 開發分支 創建；開發完成后，合并到 開發分支；
• 修復分支：當問題已經被流轉到 測試分支 及其 下游分支（比如：預發布分支、發布分支）時，則應該 基于 問題所在的 流轉鏈 中的 終點分支 創建 修復分支，修復完問題后，再將該分支分別合并到 終點分支 和 開發分支 上；否則，應當將問題的修復視作正常的開發來對待，即：可以在功能分支上直接修復，也可以基于開發分支創建一個用于修復該問題的 功能分支。
  • 測試修復分支：如果問題所在的終點分支是 測試分支，則又稱該 修復分支 為 測試修復分支；
    • 在合并前需要確保 該分支中 已經包含了 測試分支 上的所有變更；即：如果 測試分支 上有新的變更，且這些新的變更并沒有包含在該分支上，則需要：
      1. 先把 測試分支 上那些新的變更合并到該分支上，確保沒問題后，然后才能再將該分支合并到 測試分支；
      2. 然后將 開發分支 合并到該分支上，確保沒問題后，然后再將該分支合并到 開發分支 上；
  • 發布修復分支：如果問題所在的終點分支是 預發布分支 或 發布分支 ，則又稱該 修復分支 為 發布修復分支；
    1. 修復完問題后，測試人員直接在該分支上進行測試。
    2. 測試完成后，再將該分支分別合并到 母分支（即：問題所在流轉鏈的終點分支） 和 開發分支。
    3. 在合并前需要確保 該分支中已經包含了 母分支 上的所有變更；即：如果 母分支 上有新的變更，且這些新的變更并沒有包含在該分支上，則需要先把 母分支 上那些新的變更合并到該分支上，確保沒問題后（此處需要再次測試），然后才能再將該分支合并到 母分支 上；
    4. 然后將 開發分支 合并到該分支上，確保沒問題后，最后再將該分支合并到 開發分支 上；
• 合并分支：該分支是對 需要合并的多個分支 進行合并而來的分支；可用于以下場景：
  • 多個功能分支需要同時合并到開發分支；
  • 多個修復分支需要同時合并到終點分支 和 開發分支；
• 對于任意分支，在將其合并到 母分支 前，都需要確保 該分支 已經包含了 母分支 上的所有版本；即：如果該分支在合并前，母分支上有新的變更，且這些新的變更并沒有包含在 該分支上，則需要先把 母分支 上那些新的變更合并到該分支上，確保沒問題后，然后才能再將該分支合并到 母分支 上；
• 只有 發布分支、預發布分支、測試分支、開發分支 是長期分支，其它分支的都是臨時分支；
• 對于臨時分支，使用完后，應及時刪除；

注意：

• 本規范（分支的流轉規范）中所述的合并操作 可以是 一般的 分支 合并 操作，也可以是 Pull requests (Merge Reques)，這個取決于倉庫的管理策略；
• 對于那些比較重要的長期分支（比如：測試分支、發布分支 等等）上的合并操作，建議使用 Pull requests (Merge Reques) 的方式，因為 Pull requests (Merge Reques) 方便權限管理 和 操作確認；

GitFlow分支流轉規范圖