我们之前用过一个方案，和Git Flow比较类似，但是不依赖工具的支持，更多的是依靠团队本身的约定和规范。
对于开发、测试、预发、生产分别使用分支develop、test、release、master分支，其中master分支作为稳定分支，不能直接提交代码，同时这几个分支是固定唯一的分支。
首先开发阶段，大家都需要基于master创建最新的功能开发分支，命名为feature/xxx。
如果需要发布到开发环境，所有人的代码都需要合并到develop，并且只能用develop分支进行发布开发环境。
如果开发完成，需要提测的分支合并到test分支，那些还在开发阶段的就在develop好了。
测试完成之后需要发布预发(当然叫灰度、uat都行)，就把代码合并到release进行发布。
发布完成之后，代码自动合并到master。
这样做的好处就是首先规范了分支的开发和管理，开发中不会产生太多的纠纷，而且对于同时有多个需求开发并且不同时间上线都可以做到很好的管理。
缺点就是一个项目多个需求开发上线，需要合并多次代码，从develop、teest到release都要分别合并一次代码并且解决冲突。
总的来说，这只是一个基于团队的规范，对于环境和中间件CI/CD能力没有太多的要求，可以简单的套用在各个公司的场景。
阿里的解决方案阿里的解决方案基本上可以说是上面几个模式的一个结合体，称作Aone Flow，可能因为工具本身就叫做Aone吧。
分支只有3个，master分支、功能分支feature、发布分支release，其中release分支基本上是不需要开发人员来参与管理的。
首先，分支的创建也都是基于master，如果有需求，首先创建一个feature分支，部署前Aone会自动合并master代码，所以不用操心代码没有合并的问题，如果存在冲突需要手动解决，反之则就自动生成一个新的分支用于部署，这个分支就是release分支。
这个分支可以一直用来发布日常(理解成开发或者测试环境合体)、预发和生产环境。
那如果多个需求同时在开发有冲突不需要合并代码吗？首先，Aone部署可以同时部署多个分支，选择部署多个功能分支代码会自动合并，如果存在冲突需要手动解决，另外可以单独建立一个环境来部署，互不影响，这个功能真是蛮吊的。
这个规则对于预发和生产环境也是同理。
整个开发过程，我们不需要管各种分支，只需要一个feature功能分支用于发布各个环境，最终发布完成之后代码自动合并到master主分支（可选项，也可以不合并）。
整个模式看下来就是集成了各个模式的特点，参考了Git Flow的分支的特点，只不过其他的分支不用开发人员关心，基于主干master拉出分支开发，自动合并又像是TrunkBased的做法，最终整个流程对于开发人员体验下来又像是更简化版的Github Flow了。
文章参考：
?p=2165
https://mp.weixin.qq.com/s?__biz=MzAxNDU0MTE0OA==&mid=2661008528&idx=1&sn=748c3b5bdaa28c3c7b3c06614fd69d47&scene=21#wechat_redirect
https://cloud.tencent.com/developer/article/1646937