关于 GitLab Flow 的疑惑

[xiandefh]

目前公司项目开发基于 GitLab Flow 流程，既 feature->master->pre-production->production，其中 master、pre-production 与 production 均 protected。

由于经常多分支并行开发，所以 master 上一般都会包含多分支的代码。由 master->pre-production 时，研发主管需要 cherry-pick。目前遇到的问题是：

1. 每次 cherry-pick 需要选择的 commit 数目很多，容易出现遗漏或者多选；
2. 公司项目多，导致研发主管需要每个项目自行 cherry-pick，没有找到可由员工自行 cherry-pick 后发起 Merge Requests 的方法。

所以在此咨询下大家的意见。

[Hilong]

为啥需要 chery-pick， 不是预发布的不要合进去啊，在自己的 feature 分支测试完再合并啊

[xiandefh]

@Hilong 没太理解你的意思。。。比如 master 上同时有了 feature1 和 feature2 的代码，这时 master 上的 feature1 如果要上预发布，不是应该要 chery-pick 吗？

[Hilong]

保证合进 master 的代码都是能发布的，不能发布不要合进去啊，在另外的分支测试

[Sharuru]

= = 直接 feature/feature1 通过 MR 合进去啊……

[xiandefh]

@Hilong 明白了，目前我们测试服只有一个，所有要测试的代码都是合并到 master 后一起发布到测试服提测，每个分支没有单独提测。。。有改进方向了，多谢指点！

[xiandefh]

@Sharuru 但 GitLab Flow 的规范是 feature->master->pre-production，如果 feature->pre-production，总感觉会有其他问题。。比如 feature 的代码就有可能没在 master 上测试过。

[Hilong]

另外，建议每个大版本另外切一个分支出来发布，有些小问题直接合 bugfix 上去，后面再把发布分支合回 master，这样方便回退。

[xiandefh]

@Hilong 谢谢，明白了

[ouyangdd]

我也遇到了这个问题啊，我们公司的流程也是多个 feature 合并到 master 后再一起发布到测试服提测，楼主最后的流程是什么样的啊？

[xiandefh]

@ouyangdd feature 单独部署测试，测试完成要上线了，再合并到 master。

[Ryanwang]

master->pre-production 这个过程应该是尽量简单直接的，不应该过多的 cherry-pick。避免过多的 cherry-pick, 一个方法是: feature->devel->master->pre-production, 多出一个 devel 隔离，为准备发 pre-production，尽早冻结对 master 的 merge，这个方法其实把工作量留在了 devel->master 阶段。 另外一个方法是，过多的 cherry-pick 的原因可能是不需要进入 pre-production 的 patch 太多，一个方法是尽早的宣布只接受满足 pre-production 需求的 merge，其他的 patch 暂时放在 feature 分支里；或者是尽早新增一个专门的 pre-pre-production 分支出来，只接受 pre-productio 需求的 patch，等待成熟了后，pre-pre-production->pre-production