2019-11-05代码冲突其实是团队协作的投射，经常小冲突是健康的表现[呲牙]怕就怕平时没冲突，关键时候炸个雷。作者回复: 哈哈，看来你也经历过关键时候炸雷，记得在某大公司做做手机项目的时候，就有一次UI层的应用依赖了谷歌的新版本基线，而Framework往下还是老版本的，原本以为不会出什么问题，合并就发现一些基础功能显示异常，结果临时让厂商发了一版新的基础代码，在合并的过程中出现了大量的冲突，在解决冲突的时候由于一小段代码被人为删掉了，结果发布之后在特定版本的手机上发生大量的闪退问题，于是又紧急修复新版本上线，可以说是相当狼狈的一次经历。
3
2019-11-05金融行业很多都是采用多环境分支，例如存在sit,uat,prod分支，环境分支和主干分支长期并存，请问老师在这种情况下该采用怎样的分支策略？作者回复: 看来你也是金融行业的一员呀，的确我接触过的大多数金融公司都是采用你说的这种方式，基于环境的分支管理策略，我给他们的建议就是两点：
1. 不强制要求使用单一主线，但是要控制并行的版本分支，比如按照1个月1批次的发布模式，在这一月里只有一条版本分支，同时除了月末的集中上线之外，可以增加自身模块的上线频率，也就是1大多小的方式
2. 环境分支统一为发布分支，在一条分支上通过制品晋级的方式实现多环境的覆盖，也就是在测试环境验证通过后，按需部署到后续sit，uat等环境中，不再使用多环境分支来隔离，而是通过配置文件等方式来做到单一制品包加可变配置的方法 1 3
2019-11-08有个疑问问下：
“3. 每天向主干合并一次代码，如果特性分支存在超过 1 天，那么每天都要同步主干代码；”
这里是每天
a.把主干的代码合并到特性分支
b.把特性分支合并到主干分支
c.双向合并
选哪一个呢？
如果是b和c，那主干分支可能就不是随时可发布的了。
如果是a，可能最后合并回主干时，冲突会少些。展开作者回复: 你好，我也比较推荐a方法，实际上在特性没有开发完成之前，合并进主干也并没有什么实际意义，反而要引入特性开关等机制来保证这段特性没有启用，实际操作过程中特性分支定期rebase主干分支，这样既避免了双向合并，也让特性分支的历史足够清晰，推荐给你。
1 2
2019-11-07老师，我有个关于分支的问题，就是我们公司的情况是每周至少一次小发布，一个月一次固定大发布，而且有五个以上的不同应用同时开发。我们的分支命名是以日期为格式。不同日期的分支会同时开发。生产环境自己单独一条分支。
我们现在的问题是，一个小发布或大发布上线，代码融入生产分支之后，需要反向同步到其他正在开发的分支，而且经常会有代码冲突。这个给运维和开发都增加了不小工作量。想问下，您遇到过这样的情况吗？有什么好的建议来降低这个工作量吗？作者回复: 你好，我的理解只要存在并行分支，就会有同步冲突的问题，除非这些分支在代码模块划分上就已经界定清楚了，比如购物车分支，订单分支，商品分支，各自有各自的代码路径甚至仓库，不会修改同一份代码，那么自然也就不会有冲突了。
单从你的描述中，我还是没有特别清楚你们的分支策略图，比如小发布和大发布都有独立分支吗，是顺序开发吗，比如一个小发布上了之后再拉出下一个小发布分支？
如果在开发过程中，并行分支是完全隔离的，只有归并到主分支之后才会同步到其他分支，这和持续集成的理念是有冲突的，之前在一家金融企业见过的就是你说这种方式，后来改成特性分支模式，小版本大版本都从主干拉出来发布，只有共享主干，及时合并，才有可能减少冲突量，有兴趣讨论的话，可以补充一些信息，我们一起看看哈。 1
2019-11-05大会时和老师的巧遇算是一种很好的补充：其实关于老师今天的东西，可能目前在不同的企业落实和情况不一样吧？
记得看到一个老师说过DevSecOPS最难的是踏实的落地：其实这体现了一个方面就是"坑"如何去避免吧。有些坑可能不是我们是否想去避免就能避免：记得现在有同行问版本控制经理的事情，其实这块现在已经是一个完整的产品了。其实这种趋势我个人感觉非常明显：过去的一些分支当真实启动了足够的作用之后都变成真实的产品，而真实懂软件的不会是Sell出身的产品经理，深处这行多年的IT人。
走出来参加大会：反思很多很多，其实对于不同企业的策略应当是不同的。不同的版本发布策略都经历过：小企业可能每周一次足够了，可是大了就不够了，其中人与人的沟通或者说协调折中去选择合适当下的策略就变成关键了。
举个很有趣的例子，为何数据工程师很多时候是开发和产品之间沟通的桥梁，大量的时间在做产品经理和项目经理直接的中间沟通桥梁，有时甚至是灭火器？展开作者回复: 能有这样的思考说明参加大会还是很走心的，说白了别人家的东西怎么为我所用，也是我一直思考的东西，因为你面临的场景和挑战都不相同，又怎么可能用一套解法呢？这些最基本的原则是项目实施中可参考的事情，就像你说的，选择合适的策略就是能力的考验了。
你应该是我第一个见过面的网友哈，可以常沟通哈。 1
2019-12-05我们基本几个人一个项目，貌似多分支开发，主分支开发都有
2019-11-28老师，我有个问题。
在“主干开发结合特性分支的模式”分支策略中，
特性分支开发完成，代码已经集成到主干分支，主干分支并将特性分支发布后，发现特性分支上有bug要修复，是直接在特性分支上修复还是在主干分支上修复？
备注：我从文中提供的参考中学习到，特性分支并入主干，特性分支应该销毁，所以我认为特性分支的bug应该是在主干分支上修复。
期待老师的回答。展开作者回复: 你好，这里面有一个非常关键的点，就是特性是否已经发布上线了。如果特性还没有发布上线，那么特性分支自然还存在，就应该先在特性分支上修复，然后合并主线，这是为了保证特性分支上的独立性。如果说，特性已经发布上线了，那么再发现的问题就是一个新的缺陷或者需求了，可以理解为一个新的特性，所以需要重新拉出特性分支来，当然对于紧急情况，也可以Hotfix分支修复，再回归主线，这要看你们的发布模式，是向前升级，还是在线修复哈。
2019-11-22个人认为分支开发，主干发布，最根本的还是要有成熟全面的自动化测试进行支撑，当然也包含老师提到的准入门禁等等，如果没有这些东西，那还是不要选择分支开发，主干发布了，最终的结果就是主干被玩坏。所以我们现在走的是分支开发、分支测试、分支发布、再并入主干，然后再从主干打出新的开发分支。作者回复:
是的，主干质量是永恒的话题，其实分支开发，分支发布也是类似的，只要有一个集成的主分支，那么提交质量不达标，就很容易导致团队阻塞。
2019-11-05我们这目前采用的是分支开发，主线发布。感觉确实不是很爽，找个机会改了作者回复: 期待你的实践分享哈！