作者回复: 很棒

作者回复: 您提到利用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是很容易得到保证的。

作者回复: 特性分支模式下，都是从production拉取的开发分支，然后合并到master，master做持续集成，为了不影响持续集成，所以有了从master拉出来的环境分支进行部署

要考虑团队人员的能力，如果新人较多，就使用特性分支，反之使用主干开发，github flow的pull request其实也是特性分支

作者回复: gitlab几个flow，除了用于集成的master分支外，额外还配置了其他用于测试或上生产的分支。

拿带生产的分支来说，如果公司约定每周四才能发布到生产，而团队于周二在master上就集成好了V3.6版本，为了不影响后面的集成，master分支需要先merge到PRODUCTION分支，周四上线只需取PRODUCTION分支即可。

当然，gitlab flow也只是提供一个解决方案而已，只要能在发布窗口时正确快捷地找到用于发布的commit，同时又不影响集成即可。

至于提供带环境分支的，就是用分支模型来规约发布流程，保证用于上线的代码经过层层测试。做法就是约好了只能用PRODUCTION分支上线。比如通过PRE-PRODUCTION环境测试后，才能把该环境对应的分支合入到PRODUCTION分支。

作者回复: 主要还是看你能hold住哪个，比如我个人属于rubyist，所以用ruby写的gitlab肯定就是我的首选了，如果你比较偏爱或擅长go，那就gogs了。

相对来说我个人觉得gogs比较轻量化，有好处有坏处，比如你要大量二次开发，gitlab service形式就比较友好，而且最近也开源了HA方案

作者回复: 主干开发也可以有多个分支，除了master，其他是发布分支，master是用来持续集成的，也就是大家只往master push代码

特性切换不是分支，是代码或框架实现的功能，就理解为功能开关好了，也就是说有些代码即使上线了，也能通过开关保证它不工作

作者回复: 比如有些环境是独立与其他服务联调用的，为了保证master的持续集成，而又不至于污染这个联调环境，就需要一个独立分支了

作者回复: 持续交付要求至少有一条分支随时能够进行发布，只要遵循这个原则，仅2条分支并无大碍

作者回复: 最新版本应该给了和GitHub类似的解决方案，我们是对gitlab做了分片，每个分片是一个仓库，在集群之前增加了基于nodejs ssh2修改的proxy，仓库做简单的定时备份