04 | 一切的源头，代码分支策略的选择
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
选择适合的代码分支策略对于持续交付体系至关重要。本文从主干开发和特性分支开发两个角度出发，分析了不同的代码分支策略模型，包括Git Flow、GitHub Flow和GitLab Flow。主干开发适用于高要求的持续交付，但对开发团队的能力要求较高。特性分支开发提供了更多的灵活性和简化的流程，适用于不同的发布场景。文章还总结了不同情况下应选择何种分支策略，并介绍了国内知名互联网公司的代码分支策略选择和定制实践。读者可以全面了解代码分支策略的优缺点和适用情况，帮助他们做出合适的选择。文章还介绍了各种代码分支策略的特性，包括“主干开发”和“特性分支开发”两种策略的各自特性。相信在绝大多数的场景，企业会选择“特性分支开发”的策略。给出了几种主流的特性分支方法，并对比了各类策略的优劣，以及它们适用的场景。读者可以根据自己所在项目的具体情况，参考今天的内容，裁剪出最适合自己团队的分支策略。
《持续交付 36 讲》，新⼈⾸单¥59
全部留言(38)
- 最新
- 精选
康美之心 淇水之情微服务架构下，比较适合主干开发，一个微服务(含1-4个API)根据复杂性和规模通常由1-3的开发进行开发(含单元测试的开发)，1位测试进行API自动化测试开发，单元测试和API测试都集成到Pipeline上，一旦变动代码提交到master上后，就自动启动Pipeline上的build，在build这里会自动完成覆盖率100%的单元测试，单元测试通过，自动触发FVT deployment，部署成功后，自动触发FVT API自动化测试，FVT测试通过后；自动打出上线的tag号，并把这个tag号的部署到UAT，UAT部署成功后，自动触发UAT的API自动化测试，测试通过后，这个UAT的tag的就可以部署上线了。作者回复: 讲的好，主干开发除了cherry pick以外，都简单直接
2018-07-14230
禾子先生对于第二个问题，我的思考是使用github flow，虽然追求效率，但必须保证线上版本是一个稳定。大家都在开发分支中进行开发，快速测试和迭代，合并到master时冲突也少。也考虑过使用主干开发，不过但从稳定角度来说，还是选择了前者作者回复: 很棒
2018-07-138
bullboying在自动化测试还没怎么做到位的情况下，为了控制合并到master的都是经过测试的代码，我们增加了一个SIT分支。每次有新特性需要开发时，从master分支check out一个特性分支进行开发，可能涉及到多人协同开发。自测完成后先发起merge request到SIT分支，如果有冲突则不允许merge，以实现不同特性分支间的隔离。如果没冲突且有集成测试人员空闲，则完成merge并安排测试，测试通过后由masters再发起merge request将特性分支合并到master。因为之前控制了冲突，所以第二次合并理论上是没有冲突的。现在纠结的几个问题，一是想要限制不能从SIT分支pull，否则就达不到多个特性分支隔离的效果，全靠开发人员自觉；二是因为隔离冲突是为了限制在制品，但导致master和SIT分支上的代码其实是不同的，是否需要测试两次？作者回复: 您提到利用SIT分支来保证合并到master的都是经过测试，我们强烈建议使用 SmartMerge（本专栏第7讲） 来代替SIT，可以更及时地发现代码集成冲突的问题，其次可以更便捷地决策出用于上线的最大集合。 提到的第一个困惑，我们采用SmartMerge后，对应会有SmartMerge的分支，第一个问题演变为“怎么限制开发不要从SmartMerge的分支创建新分支，而只能从master分支创建新分支？”我认为这个演变过来的问题非常好。可以从两个方面着手来规范。 1）如果在gitlab UI上创建分支的话，我们可以很容易地限制只能从master创建新分支。 2）另一方面我们不打算限制git客户端的行为，仅当git客户端向gitlab服务端push新分支的时候做相应的检查。为了判断新分支是否从master拉取且尚未和其他分支做merge，只需查看该分支和master的merge-base的commit之间，是否存在merge的commit即可，如果有，则不允许push。 如果没有采用SmartMerge的方式，其实方法本质是相同的。如果短期内还是只能通过SIT分支的话，做法和SmartMerge的方式是一样的。 口诀为：在服务端直接控制新分支的创建，且拒绝客户端push不规范的新分支。 第二个困惑，假设你们尚未使用SmartMerge的方式，可以通过在你们的开发流程中额外增加一个活动来搞定。用于集成的SIT分支在编译打包前，务必和master做merge，打包测试后如果没问题的话，SIT和master分支做fast forward的检查，如果是fast forward，那么SIT merge到master分支产生的commit，内容和SIT 的HEAD是相同的，也就无需再一次进行测试了。如果你们master分支的变更只能来自SIT分支，那么这个fast forward是很容易得到保证的。
2018-07-1824
徐卫你好，问下。老师帮我看下理解对不对。主干开发是否只有一个分支，开发的代码提交到这个分支，发布也是用此分支。文中讲到的特性切换怎么做的？ 我个人理解是在那个发布的版本上打标签，特性切换是从tag上拉出一份代码部署？作者回复: 主干开发也可以有多个分支，除了master，其他是发布分支，master是用来持续集成的，也就是大家只往master push代码 特性切换不是分支，是代码或框架实现的功能，就理解为功能开关好了，也就是说有些代码即使上线了，也能通过开关保证它不工作
2018-07-123
董永刚分支类型中，带生产分支，带发布分支，带产品分支的分别是什么样的场景呢？作者回复: gitlab几个flow，除了用于集成的master分支外，额外还配置了其他用于测试或上生产的分支。 拿带生产的分支来说，如果公司约定每周四才能发布到生产，而团队于周二在master上就集成好了V3.6版本，为了不影响后面的集成，master分支需要先merge到PRODUCTION分支，周四上线只需取PRODUCTION分支即可。 当然，gitlab flow也只是提供一个解决方案而已，只要能在发布窗口时正确快捷地找到用于发布的commit，同时又不影响集成即可。 至于提供带环境分支的，就是用分支模型来规约发布流程，保证用于上线的代码经过层层测试。做法就是约好了只能用PRODUCTION分支上线。比如通过PRE-PRODUCTION环境测试后，才能把该环境对应的分支合入到PRODUCTION分支。
2018-07-1722
纳米您好 我是一个非开发的人员。弱弱问下，最后表里总结的生产分支 环境分支中，开发人员自身是check out哪个分支代码出来开发 又是往哪个分支集成呢。能否在这两个分支上帮细化下。非常感谢。 思考题2 我理解 既然人很少 迭代周期也较为宽松 可能这一周大部分人都工作在一个功能或者版本上 是不主干开发反而也可以。github flow应该肯定是ok的。作者回复: 特性分支模式下，都是从production拉取的开发分支，然后合并到master，master做持续集成，为了不影响持续集成，所以有了从master拉出来的环境分支进行部署 要考虑团队人员的能力，如果新人较多，就使用特性分支，反之使用主干开发，github flow的pull request其实也是特性分支
2018-07-1222
白天不懂爷的黑老师，您好，最近公司想用gitlab做配置中心，请问贵公司gitlab的高可用是怎么做的呢？谢谢作者回复: 最新版本应该给了和GitHub类似的解决方案，我们是对gitlab做了分片，每个分片是一个仓库，在集群之前增加了基于nodejs ssh2修改的proxy，仓库做简单的定时备份
2018-07-122
smartzs老师，主干开发 和 带发布分支模型 很像啊，带发布分支约等于主干开发了吧？作者回复: 还是有一点区别的，比如可以暂时预设多个发布分支，以针对一段时间内的多版本并行需要
2018-12-111
小胖胖gogs被gitlab 应该选择哪个？有什么区别吗作者回复: 主要还是看你能hold住哪个，比如我个人属于rubyist，所以用ruby写的gitlab肯定就是我的首选了，如果你比较偏爱或擅长go，那就gogs了。 相对来说我个人觉得gogs比较轻量化，有好处有坏处，比如你要大量二次开发，gitlab service形式就比较友好，而且最近也开源了HA方案
2018-07-131
初七之月亮带环境发布分支方法的多数适用场景是啥呢？是不是有多少套环境就多少套分支啊？作者回复: 比如有些环境是独立与其他服务联调用的，为了保证master的持续集成，而又不至于污染这个联调环境，就需要一个独立分支了
2018-07-121
