今天 leader 给了我一个任务，针对以下 git 分支需要走 CI 流程
master
iteration/*
简单翻阅了 gitlab-ci 的文档，找到了 only这个关键字，于是洋洋洒洒的写出了核心配置
only:
- master
- /^iteration\/*$/
只见 leader 轻蔑一笑，让我去测试一下 merge request 流程。
一种不祥的预感涌上心头......
gitlab-ci是 git官方的持续集成工具。
什么是持续集成呢？
持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。 每次集成都通过自动化的构建（包括 编译 ，发布，自动化测试）来验证，从而尽早地发现集成错误。 ------ 百度百科
百科介绍的已经挺全面的了，核心就在于自动化的编译，发布和测试。
这里举个例子详细解释一下。
想象一下，我们在 feature_develop分支上完成了本次的开发，提交 merge request（mr）然后合并到 master分支上
master分支接受了我们的提交，master分支代码发生了变化，如果我们此时需要检查一下刚刚的修改，我们需要手动编译发布。而持续集成能以脚本的方式帮我们完成这一系列过程。
持续集成的过程中，我们需要检测到某个分支的变化，或者某种行为的发生，从而触发自动构建的操作（上述例子中就是master分支的修改），于是我们使用了 gitlab-ci工具，它能够根据给定的配置检测行为的发生（类似于前端中的事件监听），而具体自动化工具的构建过程，由于该过程会占用大量的资源，所以我们可以交给 gitlab runner来实现。
CI 的基本流程我们已经知道了，我们也知道了 gitlab-ci 的具体作用是干嘛的了，我们回到 leader交给我的问题。在我们的 CI 过程中，其实除了自动化编译，还有个很重要的步骤，单元测试，我们的 CI会根据我们的代码自动去执行其中的单元测试部分，单元测试不通过，那么此次 mr 是不会被合并到我们的 master分支上的。
我们来看核心配置部分，根据 gitlab-ci 的文档，only 关键字能够指定具体的分支和部分行为，master和 iteration/* 分支我们已经指定完成了，每当这些分支上发生代码变化时会自动执行 CI 流程，那我们漏掉了什么步骤呢？merge request 提交，在我们 mr 提交的过程中，如果我们的单元测试没有通过，但是由于没有触发CI过程，master很可能会接受我们的 mr，而等到 master接受之后，再去执行单元测试已经没有太大的意义了，所以，我们应该在分支提交 mr 时就去执行 CI 流程，从而保证，master合并的 mr 是已经通过了单元测试的。于是，正确的核心配置应该如下
only:
- master
- /^iteration\/*$/
- merge_requests
