以下文章来源于高质效交付 ，作者董越

一千个读者就有一千个哈姆莱特，一千个项目就有一千种分支方案。这一千种分支方案里，八百个合适，两百个不合适。这两百个不合适的里面，一百个是有多余的设计，一百个是不支持该项目需要面对的一些场景。
那么问题来了，来到一个项目，怎么设计一个适合它的分支方案？又或者，拿到一个分支方案，怎么能看出来它合适不合适？从何处着手去分析它？
这个题目非常大，篇幅所限，我们大致讲一讲思路：分支是有层次的。在每个层次里，有一些分支模式，可以支持一些特定的场景。
以大家熟悉的Git Flow这个分支方案为例，我们看看怎么按层次分析它。

第一个层次是特性级分支，为每个特性（比如一个用户故事或线上缺陷等）拉出一条分支。在Git Flow里，就叫Feature分支。它是可选的。
第二个层次是集成级分支，也就是集成-测试-发布这个过程所需要的分支。在Git Flow里，有三类分支都属于集成级的分支。
首先是长期存在的一条develop分支。在简单的情况下，集成级分支可以就这么一条，就在这上面集成-测试-发布。
然后是，为了支持交叠（一个迭代还没发布的时候，下一个迭代已经开始持续集成了），于是有了从develop分支拉出的Release分支：在Release分支上进行发布前的最后的缺陷修复工作，而develop分支则改用于下一个迭代的集成。以此类推，每当有交叠需要支持时，就从develop分支拉出一条短期的Release分支，以“release-”为分支名的前缀。
最后是，每当遇到紧急发布的场景时，从master分支拉出一条短期的Hotfix分支，以“hotfix-”为分支名的前缀。
所以，在第二个层次里，Git Flow有三类分支：develop、Release和Hotfix分支，它们可以支持日常的集成-测试-发布，可以支持迭代间交叠这种情况，也可以支持紧急发布。

第三个层次是生产级分支。在Git Flow里，它就是长期存在的那条master分支。当然，如果你觉得政治正确很重要的话，那叫main也行。不论叫master还是叫main，它都代表当前生产环境中的软件版本。
Git Flow只有这三个层次。但是项目可能还需要第四个层次的版本序列分支：要有一定的分支方案，来支持并行的多个版本序列，比如一个客户端软件的1.x版和2.x版同时存在同时发展。这种情况Git Flow就支持不了了。Git Flow主要是支持SaaS型软件的开发。

不论是啥分支方案，你总是可以从这四个层次，一层一层地、条理清晰地分析。Git Flow是这样，GitLab Flow和GitHub Flow是这样，Aone Flow也是这样。1000个项目里的1000种分支方案都是这样。反正我遇到的1000个项目都是这样。要么你也试试，用它来梳理分析一下你的项目？
要是不赶趟的话，也可以读《高质效交付》这本书，书里讲得最全：