即使5个发布分支，修共性bug也应该是改动先合到master，然后分别集成测试5个分支。
改5个分支是什么操作。
  
【 在 foliver (Oliver) 的大作中提到: 】
:  维护困难啊。
:  我们现在有5个对外发布的分支，每次修改一个bug， 5分支都要修改，而且还要人工比较修改。太痛苦啊。
:  
:  【 在 cybereagle 的大作中提到: 】
--
FROM 115.199.96.*

你们这是从一个仓库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.*