前几天项目上线，出了一个很惭愧的事情，需要手动来把需要上线的功能复制到release分支上，真的很难受。
现在我们开发会准备两个分支，一个是release分支，一个是版本功能分支，hotfix直接在release上面修改了。
大家开开心心的在版本功能分支上面开发，不亦乐乎。测试通过，没问题，好的吧，和到release分支上发布吧，代号“通宵”。
没想到悲剧发生了，有一个库需要切换到tidb，线上冒烟的时候发现查询速度相当慢，还没有mysql分表来的快，其中原因我们就不纠结了。
还好是灰度发布，就一台机器，应用kill掉，然后release代码回滚到上个版本，准备把切库这个功能挪到下期，请不要纠结为什么可以，哈哈。
问题来了，因为新代码都在版本功能分支上，要么一起合，要么不合，哎呀真的是难受，最后没办法只能手动复制代码，最后还是上上去了。
通过这次经历，突然发现版本迭代当中不能只有一个功能分支，应该按照拆分的功能分开，如图：
这样如果出现有些功能有问题，release出现版本回滚的时候，就可以选择对应的功能上线，带来的问题就是分支暴增不好管理，但是现在都是分布式微服务，都是小团队作战，庆幸人少。
tag不一定要打在release分支，可以打在master分支上，对于突发情况，建议还是开一个hotfix分支，如hotfix/1.0.0，修复完上线合并到release和feature上，最后删除hotfix分支。
这是自己的一点感想，如果有不对的地方请提出，共同提高，谢谢！！！
原文：https://www.cnblogs.com/shenqiaqia/p/11186431.html