一、你遇到过吗
- 网页上点了合并，以为好了；后来才发现那一下报了错，或者有冲突，根本没合进去。
- 合进去了，打开线上还是老样子。
- 审的人还没出结论，拍板的人已经合了；合完才发现有一条该先补。
二、三件事，被当成一件
你以为的一件事是「合了」。其实是三件：
合并动作真的发生了
怎么核：合并状态显示已合入，有一个合入编号
合进去的就是审过的那一版
怎么核：合入的内容和审读时那一版比一遍，一致
线上换成了新版
怎么核：部署跑完，线上页面和它引用的每个文件逐个返回正常
办公室里「签了字」就是生效。在这里，合并、内容一致、上线是三个状态，任何一个没到，都不叫完成。
我们自己的规矩里有一句：主干就是生产。合进去的东西，下一次部署就到客户面前。
这一篇用到的词
三、先合了，才审
这一条多半出在拍板的人身上，所以单拎一节。
- 传统里，老板看过一眼说「行」，就等于审过了。
- 在这里，「看过」和「审过」不是一回事：审是逐行读改动、复跑判据、留下书面结论。合并按钮和审读结论之间，界面上没有任何东西拦着。
所以靠「记得先审」拦不住。我们的补法是两条：
闸放在流程里
- 审读结论出来之前，不给合入命令。
- 合入命令最后固定跑三行：合入状态、合入编号、与审读那一版是否一致。
按钮人人都能按，闸要放在流程里。
四、用四象限照一照
| 象限 | 在「合并」这件事上 |
|---|---|
| 已知的已知 | 点合并 |
| 已知的未知 | 它真的合进去了吗 |
| 未知的已知 | 合进去的是不是审过的那一版；合了不等于上线 |
| 未知的未知 | 这一次合并会让谁的下一次构建撞上冲突 |
五、我们自己被教育过
- 一天之内，四份改动在审读结论出来之前就合了进去。事后逐份核对，内容都和审过的那一版一致，这一次没出事；但这是运气，不是流程。
- 拍定之后要回填的提请件，有三次在回填之前就被合入，回填只能另开一份。
- 网页上点合并报了错，被当成成功；后来改用命令行重合，才真正合进去。还有一次，拍板的人以为某份改动已经合了，其实它一直因为冲突挂着。
- 合入时标题里的标记被丢掉过不止一次。小事，但说明合入那一步没人复核。
还没验过的：「合入收尾三行」刚开始固定使用，跑的次数还少；只在我们自己一家团队里用过。
这一篇讲的，是我们每天在用的方法。
看我们怎么交付