11 | 分支策略：让研发高效协作的关键要素

作者回复: 哈哈，看来你也经历过关键时候炸雷，记得在某大公司做做手机项目的时候，就有一次UI层的应用依赖了谷歌的新版本基线，而Framework往下还是老版本的，原本以为不会出什么问题，合并就发现一些基础功能显示异常，结果临时让厂商发了一版新的基础代码，在合并的过程中出现了大量的冲突，在解决冲突的时候由于一小段代码被人为删掉了，结果发布之后在特定版本的手机上发生大量的闪退问题，于是又紧急修复新版本上线，可以说是相当狼狈的一次经历。

作者回复: 你好，我也比较推荐a方法，实际上在特性没有开发完成之前，合并进主干也并没有什么实际意义，反而要引入特性开关等机制来保证这段特性没有启用，实际操作过程中特性分支定期rebase主干分支，这样既避免了双向合并，也让特性分支的历史足够清晰，推荐给你。

作者回复: 看来你也是金融行业的一员呀，的确我接触过的大多数金融公司都是采用你说的这种方式，基于环境的分支管理策略，我给他们的建议就是两点： 1. 不强制要求使用单一主线，但是要控制并行的版本分支，比如按照1个月1批次的发布模式，在这一月里只有一条版本分支，同时除了月末的集中上线之外，可以增加自身模块的上线频率，也就是1大多小的方式 2. 环境分支统一为发布分支，在一条分支上通过制品晋级的方式实现多环境的覆盖，也就是在测试环境验证通过后，按需部署到后续sit，uat等环境中，不再使用多环境分支来隔离，而是通过配置文件等方式来做到单一制品包加可变配置的方法

作者回复: 能有这样的思考说明参加大会还是很走心的，说白了别人家的东西怎么为我所用，也是我一直思考的东西，因为你面临的场景和挑战都不相同，又怎么可能用一套解法呢？这些最基本的原则是项目实施中可参考的事情，就像你说的，选择合适的策略就是能力的考验了。 你应该是我第一个见过面的网友哈，可以常沟通哈。

作者回复: 你好，我的理解只要存在并行分支，就会有同步冲突的问题，除非这些分支在代码模块划分上就已经界定清楚了，比如购物车分支，订单分支，商品分支，各自有各自的代码路径甚至仓库，不会修改同一份代码，那么自然也就不会有冲突了。 单从你的描述中，我还是没有特别清楚你们的分支策略图，比如小发布和大发布都有独立分支吗，是顺序开发吗，比如一个小发布上了之后再拉出下一个小发布分支？ 如果在开发过程中，并行分支是完全隔离的，只有归并到主分支之后才会同步到其他分支，这和持续集成的理念是有冲突的，之前在一家金融企业见过的就是你说这种方式，后来改成特性分支模式，小版本大版本都从主干拉出来发布，只有共享主干，及时合并，才有可能减少冲突量，有兴趣讨论的话，可以补充一些信息，我们一起看看哈。

作者回复: 你好，这里面有一个非常关键的点，就是特性是否已经发布上线了。如果特性还没有发布上线，那么特性分支自然还存在，就应该先在特性分支上修复，然后合并主线，这是为了保证特性分支上的独立性。如果说，特性已经发布上线了，那么再发现的问题就是一个新的缺陷或者需求了，可以理解为一个新的特性，所以需要重新拉出特性分支来，当然对于紧急情况，也可以Hotfix分支修复，再回归主线，这要看你们的发布模式，是向前升级，还是在线修复哈。

作者回复: 是的，主干质量是永恒的话题，其实分支开发，分支发布也是类似的，只要有一个集成的主分支，那么提交质量不达标，就很容易导致团队阻塞。

作者回复: 期待你的实践分享哈！