你们这是从一个仓库fork出5个项目去开发了，不要说是5个发布分支。搞定制化开发搞到不顾整体产品规划，那这帮不了你了。
Release分支的通常只在每次实际发布新版本的时候产生，不会往一个已经release的分支里不断堆代码，这没法管理。
举个例子，比如说决定发布1.1版本了，有AB两个使用场景，代码库里有共同代码和不同场景的可选模块，拉两个分支 v1.1.0-A-rc和 v1.1.0-B-rc，A-rc里配置文件根据A场景需求修改，B同理，两个分支分别去集成测试发布，产生v1.1.0-A和v1.1.0-B。后续维护看情况，不紧急的bugfix进master分支，跟着下个版本比如1.1.1发布，紧急的hotfix直接进 A release分支，再讨论是否要吸收到master分支，也有可能hotfix的修复方法太针对只能临时用，就不进master的。
【 在 KingPower (红宝石) 的大作中提到: 】
: 这种思路是按照最后都是一个合并主干来设计的吧
: 很多实际情况我们就是要求不同的地区不同的分支，未来永不合并那种
:
: 【 在 StephenLee (薛定谔的猫) 的大作中提到: 】
--
FROM 61.242.130.*