精选留言(5)

• 
  加载中……

  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
• 
  iuSugar

  2019-05-19

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

  作者回复: 用gitlab flow的做法，每开发一个新功能，先从主干拉出“特性分支”，待特性分支自测通过后，再把特性分支上的功能合入主干分支（分享给团队使用）。

  

  
• 
  加载中……

  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通过质量检查（允许发布）也是一个方法。

  

  
• 
  弥勒秋实

  2019-01-09

  玩法还挺多

  

  
• 
  我来也

  2019-01-04

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

  

  