老师，请问“特性分支”具体是干啥的？不是很理解这个特性分支

您好，我读了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非常不稳定

您好，请教个问题，如果采用特性分支开发方式（即：一个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，还是怎么做？ 不知道您的团队是按照什么方案来做的？

我们团队用的是git flow，感觉还是挺好的

回忆一下我们的流程： 1：开发新功能，一定从master拉新分支 2：开发完后，自测加提测 3：测试先进行分支测试 4：分支测试完后，进行代码review 5：合并主干，进行主干回归测试 6：上线，产品和业务进行线上验证 7：如果涉及多个组，在合住干前，需要进行预发布联调测试 8：如果因业务或功能限制，上线后可能会通过开关控制，部分切量试运行

从这开始听不懂了。

听到这里，发现前面偏基础，但可以很好去实践，而到这里听着很悬，但是这块一定是精华，可是没有实操的机会。

回忆下我们的流程： 1.开发新功能从beta分支拉去feature_x_x分支 2.开发完合并dev联调自测 3.dev合并beta测试人员回测 4.合并master

玩法还挺多

长见识了，这么多工作流。 有利有弊，可以很好的参考。 我目前还是自己一个人玩git，比较原始。😄