我的开源项目收到第一个PR，但合并前这些检查必须做#

哟，本宫瞧瞧，这是谁的眉头都快舒展开了？嘴角都快咧到耳根子了？是不是刚在GitHub上收到了人生第一个PR，感觉整个世界都为你开花了？先别急着把那“Merge”按钮点出火星子来，美得跟什么似的。听本宫一句劝，你现在这状态，跟那刚登基就以为天下太平的愣头青皇上没两样。皇上臣妾都不敢这么看着他得意忘形，你倒好，人家给你个PR，你就恨不得把江山都许出去了？

行了，收起你那没见过世面的笑。收PR是喜事，但直接合并，那就是给你自己的项目埋雷，还是哑雷，炸的时候连声儿都没有，就看你项目代码的尸体有多惨了。今天本宫就屈尊降贵，给你这刚入宫……哦不，刚入开源圈的小答应立立规矩。合并之前，这些检查，少一样，本宫都替你慌。

第一节：先别急着验货，看看这“进贡”的流程合不合规矩

你以为人家提个PR，代码写了就行？天真！你项目里那CI（持续集成）是摆着好看的吗？还是说你压根就没给本宫配？那本宫可要骂你了，活该你现在手忙脚乱。

第一个要看的，就是PR页面那个绿色的小勾勾。不是让你瞅着它傻乐，是让你确认，这个勾勾，是通过了你项目所有的自动化检查后才亮的。 每一个绿勾，都代表测试、构建、代码风格检查跑了一遍没出事。要是红叉叉，或者干脆没跑，你合并个鬼啊？你这是在请个祖宗进来，还是帮你找bug？

具体怎么查？点进PR详情页，往下翻，找到“Checks”那个标签页。里头列出来的，就是这个PR经历的所有自动化考验。每一个都要点开，看看是不是全绿。要是有失败的，不用本宫教你吧？在评论区@那位贡献者，客气但清晰地告诉他：“亲爱的，您的代码把臣妾的测试花园给炸了，请您收拾妥当再来。” 什么？你说你没设CI？那你现在关掉本宫这篇文章，先去把CI配好，这是底线，懂？

第二节：别光看绿勾勾，去看看他说了些什么“梦话”

代码是给人看的，不是只给机器跑的。一个PR交上来，贡献者总得说说他这代码是来干嘛的吧？是为了修一个闪退，还是加一个花里胡哨的功能？

你得去看他填写的PR描述（Description）。 他有没有说清楚：1. 解决了什么问题？2. 怎么解决的？3. 可能影响了哪些部分？如果他写得云里雾里，只写了个“fix bug”或者“add feature”，本宫建议你直接在评论区温柔（bushi）地追问：“阁下这描述，写得跟臣妾的谜语一样，不如展开讲讲？” 拒绝合并描述不清的PR，这是对你项目的负责，也是对其他贡献者的尊重。不然以后出了问题，你都不知道问题出在这位“刺客”的哪个招式里。

第三节：拉到本地，让你的“江山”亲自验验货

很多人就死在这一点上：只看线上绿勾，从不本地测试。本宫问你，你代码是在服务器上跑的，还是在你自家电脑上跑的？你敢保证GitHub的测试环境和你一模一样吗？尤其是涉及UI、网络请求或者特定环境的代码。

正确的姿势是： 把这个PR的代码拉到你本地分支。通常贡献者会开一个专门的分支，你可以用类似 git fetch origin pull/ID/head:PR_BRANCH 这样的命令把它弄下来。然后，切换到这个分支，跑一下你本地所有的测试，再把整个项目跑起来，手动去点点、戳戳，看看他改的地方是不是真的如他所说，而且没把你别的地方搞坏。

这个过程最能看出问题。比如，他修好了A页面的按钮，结果B页面的显示错乱了——这种“医好了咳嗽，瞎了眼”的骚操作，本地一试一个准。别偷懒，这一步你亲手做了，合并的时候才心里有底。

第四节：过代码，不是让你阅奏折，是让你当侦探

好，现在流程OK，描述清楚，本地也测过了。最后一步，也是最重要的一步：Code Review，代码审查。

别一听“审查”就头大，以为要逐行逐句看。你是侦探，不是批阅奏折的皇上。你的目标是发现隐患。重点看这几点：

1. 安全性： 有没有不小心把API密钥、数据库密码这种要命的东西提交上来？这是红线，碰了就得让他重提。
2. 可维护性： 他的代码是写得像一团意大利面，还是清清楚楚，函数/变量名有意义？别接手一堆谁也看不懂的“天书”，以后改代码就是给自己上刑。
3. 一致性： 他有没有遵循你项目原有的代码风格？比如缩进、命名规范。如果他的代码看起来像个混搭怪，让他去调整，或者你在合并后自己花时间整理（但别惯这毛病）。
4. 逻辑合理性： 他为了解决一个小问题，是不是引入了巨大、复杂的依赖？或者用了一个特别绕的写法？有时候简单直接才是王道。

发现问题，在评论区一条条指出来，语气可以像本宫这样“阴阳怪气”一点：“哟，这位大人的这段逻辑，绕得臣妾头晕，不知可否赐教？” 但核心是讨论技术，不是人身攻击。这是为了让代码更好，不是为了显摆你多厉害。

第五节：合并之后，还有最后一哆嗦

终于，万水千山都走完了，绿勾勾全亮，描述清清楚楚，本地没问题，代码也顺眼。你可以点那个“Merge pull request”按钮了。哦对了，合并方式也看一眼，“Create a merge commit”还是“Squash and merge”？根据你项目的习惯来，别瞎选。

合并完，记得跟贡献者真诚地说一声“Thanks”，甚至可以在你的CHANGELOG或者公告里提一嘴。人家贡献了代码，你收获了功能，这是开源世界最美的样子。但你的工作还没完，赶紧去你自己的本地主分支 git pull，再跑一遍测试！ 确认一下合并后的“江山”稳固无虞。

所以啊，小主，收到PR是万里长征第一步，合并前的检查才是你守护项目江山的真功夫。别光顾着高兴，去，按本宫说的，一条条检查去。等你熟练了，你就会发现，最开心的不是有人帮你写了代码，而是你亲手把一份靠谱的代码，稳稳当当地接进了你的世界里。这可比皇上翻牌子有成就感多了，你说是不是？