2019-02-18您好，我读了LM的那个文章，还有一些疑问，麻烦解答，谢谢。
首先：LM 确实可以高效定位可集成的特性分支的最大集合。
1、疑问一：LM工作原理
①自动从master分支拉出一个LM分支(分支名称有一定策略，可能是根据特性分支来的)，比如lm_f1_f2..._fn
②然后把特性分支f0,f1..fN，合并到这个LM分支lm_f1_f2..._fn
③这个时候lm分支lm_f1_f2..._fn就是全量的了
④如果某个分支由了更新，再把更新分支merge到lm分支lm_f1_f2..._fn
2、疑问二：测试人员针对哪个分支做全量测试（针对一个中型需求测试周期也不会短）
①是lm分支？
如果是这种即：等测试完成后，再merger到master。不能保证在测试期间，master没有改变，也就不能保证merger不引入冲突，冲突解决冲突的时候就有可能产生bug。
我看文章的意思应该是如果组成lm分支的某个分支变化了，会自动合并到lm分支，即使是这样准实时同步，会很大程度减少合并到master的冲突，也不能杜绝吧？
②还是正式merger到master后再介入测试
如果是这种，即会把不稳定的commit先merge到master，然后测试也会有一段周期。这段周期内如果又有新的紧急需求和bug要上线就比较尴尬了。
3、疑问三：如果没有lm，采用特性分支，一般的流程会是怎么样的
①：先基于特性分支测试，再合并master上线
我感觉，这种比较好一点，但是没法解决合并master的冲突
②：先合并master，再测试，上线
我感觉这种不好，这种会使master非常不稳定展开作者回复: 好问题，等有空了，我再来好好聊聊
1 3- 2019-02-17您好，请教个问题，如果采用特性分支开发方式（即：一个master多个特性分支）。比如：有个特性分支f1已经开发完成后还没测试，应该才采取下面那个方案：
方案1：
1、测试人员基于f1分支完成测试功能
2、合并f1到master
3、上线master
方案2：
1、合并f1到master
2、基于master(或拉取一个production分支)做测试
3、上线production
如果采用方案1，我感觉有以下缺点
在第二步骤其实并不能保证没有合并冲突或合并过程中产生的bug。所以步骤1的测试意义不大。
如果在merge完成后再测试一遍，又浪费测试资源和时间。
如果采用方案2，我感觉缺点是：
如果合并到master后，业务方或其他原因说又不上线了。如果这时候又有一个需求f2要上线，还得把master上合并的f1分支剥离下来，这个剥离的具体做法是对f1 merge的节点进行revert，还是怎么做？
不知道您的团队是按照什么方案来做的？展开作者回复: 好问题 👍，嘴贴切的参考资料如下：
干货 | 分支集成加速器Light Merge在携程的应用
https://mp.weixin.qq.com/s/nH6RR9YyUKydxBqJaQ2Okg
另外，GitLab社区也在讨论类似的问题，在Merge Request的open状态下，增加“临时merge”的质量检查，而不仅仅只查source分支。
当然，如果公司有专门的发布系统，它会标示master上哪个commit通过质量检查（允许发布）也是一个方法。 1 
2019-05-19老师，请问“特性分支”具体是干啥的？不是很理解这个特性分支作者回复: 用gitlab flow的做法，每开发一个新功能，先从主干拉出“特性分支”，待特性分支自测通过后，再把特性分支上的功能合入主干分支（分享给团队使用）。
2019-01-09玩法还挺多
2019-01-04长见识了，这么多工作流。
有利有弊，可以很好的参考。
我目前还是自己一个人玩git，比较原始。😄