作为广为流传的 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分支流转规范图