这是一个创建于 2240 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前公司项目开发基于 GitLab Flow 流程，既 feature->master->pre-production->production，其中 master、pre-production 与 production 均 protected。
由于经常多分支并行开发，所以 master 上一般都会包含多分支的代码。由 master->pre-production 时，研发主管需要 cherry-pick。目前遇到的问题是：
- 每次 cherry-pick 需要选择的 commit 数目很多，容易出现遗漏或者多选；
- 公司项目多，导致研发主管需要每个项目自行 cherry-pick，没有找到可由员工自行 cherry-pick 后发起 Merge Requests 的方法。
所以在此咨询下大家的意见。
11 条回复 • 2019-02-22 17:58:08 +08:00
 |
1
Hilong 2018-09-20 20:59:00 +08:00 via Android  1
为啥需要 chery-pick， 不是预发布的不要合进去啊，在自己的 feature 分支测试完再合并啊
|
 |
2
xiandefh OP @Hilong 没太理解你的意思。。。比如 master 上同时有了 feature1 和 feature2 的代码，这时 master 上的 feature1 如果要上预发布，不是应该要 chery-pick 吗？
|
|
3
Hilong 2018-09-20 21:08:23 +08:00 via Android 1
保证合进 master 的代码都是能发布的，不能发布不要合进去啊，在另外的分支测试
|
 |
4
Sharuru 2018-09-20 21:12:24 +08:00
= = 直接 feature/feature1 通过 MR 合进去啊……
|
|
5
xiandefh OP @Hilong 明白了，目前我们测试服只有一个，所有要测试的代码都是合并到 master 后一起发布到测试服提测，每个分支没有单独提测。。。有改进方向了，多谢指点！
|
|
6
xiandefh OP @Sharuru 但 GitLab Flow 的规范是 feature->master->pre-production，如果 feature->pre-production，总感觉会有其他问题。。比如 feature 的代码就有可能没在 master 上测试过。
|
|
7
Hilong 2018-09-21 09:57:44 +08:00 via Android 1
另外，建议每个大版本另外切一个分支出来发布，有些小问题直接合 bugfix 上去，后面再把发布分支合回 master，这样方便回退。
|
 |
9
ouyangdd 2018-10-08 11:55:59 +08:00
我也遇到了这个问题啊，我们公司的流程也是多个 feature 合并到 master 后再一起发布到测试服提测，楼主最后的流程是什么样的啊？
|
 |
11
Ryanwang 2019-02-22 17:58:08 +08:00
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
|
Select Language