具体来说，如果用户 push 或 merge request，触发 pipeline 去执行构建和测试，当然是合理的。
但是，如果测试的只是他提交的这个 branch，那显然是不充分的，因为存在一种边界情况是:测试在 source branch 上能通过，在 master 上也能通过，但 merge 执行后反而不能通过。

也就是说，当有两个人分别修改了代码的不同部分，但这两部分又有隐含的逻辑相关性，那么就存在一种可能是，两个人的代码都能跑过，但合到一起会跑不过。

所以期望 gitlab CI 在被 merge request 触发后，不是做当前 source branch 的构建和测试，而是把这个 branch 与 master 做一次预合并，再基于合并后的代码做构建和测试。

想问下这种需求的最佳实践是怎样操作？直接在 build stage 里写 git 操作的 script 来执行 merge 吗？还是有别的聪明的办法？
按我理解这个需求是很常见的，Gitlab CI 也许内建了这个功能。但是没搜到。

以前在大厂都是前辈们全部配好的直接用，现在在小公司，需要自己管 CI，才发现这东西不是想的那么简单。