先贴上gitlab上的图，再贴上对话。
（情景：我git pull --rebase 出了冲突，自己没发现。）
隔壁学长：没有机器人 只能手动关注CI了
你merge 冲突没处理完
我：我把id改成packageName了呀，没报错啊
隔壁学长：等dev CI过了以后再提
我：CI是啥学长
隔壁学长：Google
------------------------------------------------------
持续集成Continuous Integration（CI） , 持续交付Continuous Delivery（CD)
简单理解，在一个制造罐头的工厂里面，一个火腿罐头的生产流程：加入各种食品材料，合成超级肉饼， 切片肉饼成单个罐头大小， 取罐头包装盒，放入，密封，贴上标签，出厂。
如何完成这个过程，整体的设计，这叫做CD。
启动生产的流水线，在流水线中进行操作，优化，处于生产的过程中，叫做CI。
在软件开发的意义上：
持续集成（CI）是在源代码变更后自动检测、拉取、构建和（在大多数情况下）进行单元测试的过程。
持续集成是启动管道的环节（尽管某些预验证 —— 通常称为上线前检查pre-flight checks
—— 有时会被归在持续集成之前）。
持续集成的目标是快速确保开发人员新提交的变更是好的，并且适合在代码库中进一步使用。
持续集成的基本思想是让一个自动化过程监测一个或多个源代码仓库是否有变更。
当变更被推送到仓库时，它会监测到更改、下载副本、构建并运行任何相关的单元测试。
目前，监测程序通常是像 Jenkins 这样的应用程序，它还协调管道中运行的所有（或大多数）进程，
监视变更是其功能之一。监测程序可以以几种不同方式监测变更。这些包括：
轮询：监测程序反复询问代码管理系统，“代码仓库里有什么我感兴趣的新东西吗？”
当代码管理系统有新的变更时，监测程序会“唤醒”并完成其工作以获取新代码并构建/测试它。
定期：监测程序配置为定期启动构建，无论源码是否有变更。理想情况下，如果没有变更，
则不会构建任何新内容，因此这不会增加额外的成本。
推送：这与用于代码管理系统检查的监测程序相反。在这种情况下，
代码管理系统被配置为提交变更到仓库时将“推送”一个通知到监测程序。
最常见的是，这可以以 webhook 的形式完成 ——
在新代码被推送时一个挂勾hook的程序通过互联网向监测程序发送通知。
为此，监测程序必须具有可以通过网络接收 webhook 信息的开放端口。持续交付（CD）通常是指整个流程链（管道），它自动监测源代码变更并通过构建、测试、打包和相关操作运行它们以生成可部署的版本，基本上没有任何人为干预。
持续交付在软件开发过程中的目标是自动化、效率、可靠性、可重复性和质量保障（通过持续测试）。
持续交付包含持续集成（自动检测源代码变更、执行构建过程、运行单元测试以验证变更），持续测试（对代码运行各种测试以保障代码质量），和（可选）持续部署（通过管道发布版本自动提供给用户）。
上面场景中我没有自动化检测，所以学长说了手动CI。我在gitlab上的CI/CD选项中的Jobs可以查看是否有冲突。
上一次那个报错了，然后学长给我发现了。我自己没发现。然后我重新git.，自己去看。
我说我去git一下，又被学长打趣了：用语要准确 不然看起来不专业
学长推荐了：
