开源协作实战：从规范提PR到高效Review的完整指南

说起来有点丢人我最早提 PR 的时候干过不少让维护者看了直摇头的事往 master 分支直接推代码、Commit message 写 update、fix bug 这种看了等于没看的描述、PR 描述里一个字都不写就点创建。当时我还觉得代码能跑不就行了直到被一个项目维护者在评论里礼貌地教育了一顿我才开始认真琢磨一件事到底什么样的 PR 才算规范。后来参与的开源项目多了自己也做了维护者收到过几百个 PR我才真正明白规范地提交 PR 不是为了好看而是为了降低协作成本。你和维护者之间隔着网络、隔着时区、隔着不认识的人你的 PR 能不能被顺利合入很大程度上取决于你替对方省了多少麻烦。这篇文章我就把一套完整、实用的 PR 提交流程给你捋清楚配合图文说明从 fork 仓库一直讲到 review 反馈后的更新帮你从一开始就走对路子。适合刚接触开源贡献、或者提过几次 PR 但总被要求修改的同学。1. 从能提PR到会提PR规范到底规范在哪先想一个问题PR 的本质是什么它不是我把代码发给你而是我基于你的项目做了一些改动请你审查并决定是否合并。这是一个请求不是一次提交。既然是请求姿态和方式就很重要。很多刚入门的同学对 PR 有个误解觉得代码写对就行了。其实在真实的开源项目里维护者审查一个 PR看的顺序通常是先看 PR 描述清不清楚再看分支和提交历史干不干净然后才看 diff代码改动最后自己跑一遍测试。你的代码写得再好如果前面几步一塌糊涂很可能被拖着迟迟不合并甚至直接被关闭。那规范具体指什么我把它拆成四个层面流程层面不用 master 分支直接改而是用独立的功能分支保持分支和上游仓库同步不把无关改动混进同一个 PR。提交层面Commit message 语义清晰遵循项目的提交规范每个 commit 只做一件事历史整洁没有一堆 fix typo 之类的垃圾提交。描述层面PR 标题和描述写清楚做了什么、为什么做、怎么验证的必要时附带截图和测试结果。沟通层面收到 review 反馈后及时响应、礼貌回复更新 PR 的方式要正确不覆盖协作者的工作。这四个层面不是各自独立的它们共同服务于一个目标让维护者用最少的时间理解你的改动并放心地把它合并进去。说白了提交 PR 是一次社交行为 工程行为规范本身就是你专业度的体现。顺便说一个我当维护者之后特别有感触的现象很多 PR 本身代码质量不错但败在了包装上。比如分支只写了一串乱码似的哈希或者描述里只有一句fix issue我得点开 diff 才能猜他想干什么。反之那些模板填得工整、commit 历史清晰的 PR我会下意识地更认真地 review也更愿意在评论区多给一些指导。人都是这样你尊重对方的时间对方也会尊重你的代码。这篇文章后面所有的内容都是围绕这四个层面展开的。你按这套流程走提 PR 这件事基本就不会再出大问题。2. 提PR前的地基工作仓库准备与分支管理很多教程一上来就讲怎么点 New Pull Request但我觉得那一步其实是最简单的点两下按钮而已。真正决定你 PR 体验的是之前一个小时的准备工作。这部分做得好后面所有环节都顺。2.1 Fork把项目复制到你名下进入你感兴趣的开源项目主页点右上角的Fork按钮在弹出界面确认一下仓库名和描述然后 Create fork。这一步是在 GitHub 服务器端把原仓库复制一份到你的账号下你自己的这份副本你想怎么折腾都行不影响原项目。Fork 完成之后你需要在本地把代码拉下来。这里有个细节Fork 出来的仓库地址和你 clone 的仓库地址要分清。很多人只 clone 了自己 fork 的那个地址后面想同步原仓库的最新代码时会一脸懵。我建议的做法是fork 完成后直接执行# 用你自己的 fork 地址 clone 到本地 git clone gitgithub.com:你的用户名/项目名.git # 进入项目目录 cd 项目名clone 用的是 SSH 还是 HTTPS 取决于你本地是否配置了 SSH key。个人强烈建议配置 SSH因为这个地址是gitgithub.com:...后面 push 代码免密、安全不会像 HTTPS 那样每次要输入账号密码或者用到 Personal Access Token稍微麻烦一些。2.2 设置 upstream给本地仓库装一个上游雷达clone 完之后有个一步必做但特别容易被新手忽略的操作把原仓库添加为 upstream 远程源。git remote add upstream gitgithub.com:原组织名/项目名.git注意原组织名不是你的用户名是项目所属的组织或作者。执行完可以看一下当前配置确认无误git remote -v正常情况下你应该看到四个远程地址两个指向你 clone 时的远程通常是 origin两个指向 upstream。这就是你这台电脑连接的两端origin 是你自己的 forkupstream 是项目本体。为什么必须配 upstream因为开源项目每天都在更新。你 fork 下来的版本是个快照过几天就跟不上原仓库了。没有 upstream你就没法在本地拉取项目的最新代码提的 PR 很容易跟最新代码冲突。有了它一条命令就能同步git fetch upstream2.3 分支管理永远不在 master 上动手术接下来是分支策略。我见过的所有资深开源贡献者几乎都有一个共同的铁律永远不要在你的 master/main 分支上直接改代码、直接推提交。原因很朴素master 分支是用于跟 upstream 保持同步的镜像分支它应该是干净的。如果你在它上面改了一批代码之后再想git pull upstream main同步最新代码就会和你的本地改动纠缠在一起冲突处理非常痛苦。正确做法是每个 PR 开一个独立的新分支。比如你要修一个文档里的小 bug或者加一个新功能# 先确保 master 是最新的 git checkout master git pull upstream master # 创建并切换到新的功能分支名字要有语义 git checkout -b fix/docs-typo分支命名的规范这里多说两句。不要用patch-1、update-2这种 GitHub 网页端自动生成的名字虽然网页端改文件确实会这样但本地操作完全可以避免用类型/简短描述的格式一眼能看出这个分支是干什么的fix/login-page-crashfeature/user-avatar-uploaddocs/update-install-guiderefactor/cleanup-api-client这样做有两个好处你切分支时知道自己在干什么维护者看你的 PR 时也能从分支名初步判断改动方向。另外一个小技巧是分支名里不要出现中文字符和特殊符号纯字母、数字、连字符最安全。2.4 保持分支同步PR 前的关键一步假设你开这个分支已经两周了期间上游项目被别人合入了大量新代码。你提 PR 之前必须同步一次否则大概率冲突。同步方式有两种思路思路 A把上游最新的改动合并到你的功能分支git checkout fix/docs-typo git fetch upstream git merge upstream/main思路 B把功能分支 rebase 到上游最新代码之上git checkout fix/docs-typo git fetch upstream git rebase upstream/mainmerge 和 rebase 的区别一句话能说清merge 会产生一个分叉再汇合的节点历史不是直线rebase 是把你分支上的提交拔起来重新种到目标分支最新提交之上历史是一条直线。虽然网上关于该用哪个吵翻天但我在给开源项目做贡献时更倾向 rebase因为 PR 的历史看起来会非常干净——你提的 PR 里就只包含你自己改的那几个 commit跟主线的最新状态严丝合缝。提示rebase 会改写你本地提交的历史如果你已经把分支 push 到远程 fork 了并且知道可能有别人基于你的分支在协作多人在同一 fork 上开发那 rebase 前要谨慎以免改写掉别人的提交。单人做贡献的场景基本没这个问题。同步完之后记得验证一下当前代码能不能正常跑至少把已有的测试跑一遍再提 PR。千万不要同步完连构建都没跑就把 PR 扔出去那是把风险往维护者身上推。3. Commit信息的规范让项目历史像一本清晰的账本代码是写给机器执行的但 commit message 是写给人看的。维护者在 review 你的 PR 时第一眼看到的不是代码而是提交历史。如果你的提交历史是一团乱麻对方的耐心会迅速耗尽。3.1 为什么 commit message 如此重要想象这样一个场景一个项目发布了一个新版本用户反馈某个功能坏了维护者需要快速定位哪个提交引入了问题。如果每条 commit 都写得清清楚楚git bisect二分查找几分钟就能定位如果提交信息全是 update、fix你连排查的欲望都没有。更现实的是commit message 是 PR 审查者的阅读地图。他看到一个 commit 标题写着fix: correct token refresh race condition心里就有数了知道该重点看哪段逻辑如果看到的是update他只能自己去 diff 里猜这种 PR 谁看了都头疼。3.2 Conventional Commits 规范社区里最有共识的提交规范是Conventional Commits约定式提交。它的精炼格式是type(scope): subject常见的type类型我整理了一张表类型含义典型场景feat新功能新增接口、新增页面、新增组件fix修复 bug修复崩溃、修复逻辑错误docs文档变更更新 README、注释style格式调整修改缩进、补分号不涉及逻辑refactor重构重命名变量、拆分函数行为不变test测试相关新增测试用例、修改测试代码chore杂务更新依赖、修改构建脚本perf性能优化优化查询速度、减少内存占用build构建系统修改 Dockerfile、CI 配置ci持续集成修 GitHub Actions 工作流scope是可选的写影响的范围比如feat(api)、fix(auth)。subject用祈使句描述这次改动做了什么不要写得像描述状态要写做了什么事比如 add user login endpoint 而不是 user login endpoint added。完整的 commit 还可以有 body正文和 footer脚注。body 说明为什么要这么做、改动的思路footer 常用BREAKING CHANGE:标记破坏性变更或者用Closes #123关联 issue。一个规范的例子fix(auth): correct token refresh race condition The previous implementation checked the token expiry before the async refresh completed, which could cause a race condition under concurrent requests. Move the refresh into a single mutex-protected queue to ensure only one refresh happens. Closes #1024对比一个反面教材update这种 commit 等于没写。如果你用了git commit时没填信息Git 默认会让你进入编辑器新手常常直接 :wq 退出导致提交信息是空的。每次提交前花一分钟把信息写好是成本最低的协作贡献。3.3 一个提交只做一件事与 commit message 规范配套的是提交粒度。你最好不要把一个 PR 里所有改动塞进一个巨大的 commit也不要把一个改动拆成五个互相纠缠的 commit。理想状态是每个 commit 是一个逻辑独立的改动单元可以单独被理解、被 revert。举个例子你想给一个项目加用户头像上传功能顺手发现了登录页有个 display bug。正确做法是开两个分支或者至少分两个 commit一个 commit 只加头像上传另一个 commit 只修 bug。如果你把两个毫无关系的改动塞在一起维护者 review 时很难聚焦万一第一个功能需要大改第二个修好的 bug 也被拖着合不进去。如果历史已经写乱了怎么办别慌还有补救手段# 把最近 n 个 commit 合并成一个并重新编辑提交信息 git rebase -i HEAD~n进入交互界面后把非首个 commit 前的pick改成squash简写s保存后 Git 会把你写的所有提交信息汇总成一个编辑器让你重新写。这就是所谓的整理历史在你 push 之前做多少次都行。3.4 commit 里不要出现的内容再说几条我踩过坑之后的硬性注意点不要把密钥、token、密码提交进代码。一旦 push 到公开仓库密钥就等于泄露了。这在审查时是非常严重的红线大项目会直接关闭 PR。不要把 IDE 配置文件、编译产物提交进去。确保.gitignore正确配置。很多新手的 PR 里混入.idea/、.vscode/、node_modules/之类的文件维护者看到就会皱眉。不要用git add .无脑添加所有文件。先git status看清楚改了什么再git add单一文件或文件列表最后git diff --cached检查一遍再提交。提示每次 commit 前养成的习惯是git status看改了哪些文件→git diff看具体改动内容→git add精确添加→git commit写清楚信息。这一步流程多花两分钟能帮你在后面省两小时。4. 推送代码与创建PR的完整流程到了这一步你的本地功能分支上有几个干净的 commit你已经 fetch 过 upstream测试也跑过了。现在终于可以推到远程并创建 PR 了。4.1 推送分支到远程推送之前先确认你当前的分支git branch --show-current然后执行git push -u origin fix/docs-typo这里的-u意思是把本地分支和远程分支关联起来后续你直接用git push就能推不用再写全参数。推送成功后终端的输出里会直接给你一个链接类似remote: Create a pull request for fix/docs-typo on GitHub by visiting: remote: https://github.com/你的用户名/项目名/pull/new/fix/docs-typo直接复制这个链接到浏览器打开GitHub 会直接把你带到创建 PR 的页面。如果在推送时提示因为分支落后而 push 失败那说明远端有人在你之前 push 过更新的代码。处理方式是先git pull --rebase origin fix/docs-typo拉取并变基再重新推送。这里我再三提醒不要用git push --force去覆盖远程分支除非你明确知道自己在做什么。4.2 创建 PR 的页面细节进入 New Pull Request 页面后你会看到三块核心区域base 与 compare 的选择器这是最容易选错的地方。base repository和base应该选原项目不是你的 fork分支选原项目的main或master看默认分支compare repository选你的 forkcompare选你的功能分支。我的手速记忆法是左边是别人的 main右边是我的 branch。选对了GitHub 会显示 Able to merge代表没有冲突如果显示 There isn’t anything to compare多半是选反了。标题Title直接沿用你 commit 里最核心的那条信息即可。规范的做法是fix(auth): correct token refresh race condition简洁、语义清晰跟你的提交规范保持一致。描述Description这里就是下一章节要重点讲的 PR 描述。先别急着点绿色按钮确认你的描述够不够信息量。创建 PR 时还有一个实用的弹层选项Create draft pull request。如果你这个 PR 只是半成品、还在开发中可以先发 Draft PR等于昭告天下这个 PR 先别合我还想改。把功能做完、测试通过后点 Ready for review 把它转为正式 PR。这样做法既展示了进展又不会给维护者添乱。4.3 创建后的自查动作很多新手创建完 PR 就觉得完事了其实发布后你需要立刻做两步自查第一重新看一遍 Files changed 标签页。GitHub 会列出你所有改动过的文件和具体 diff。翻一遍特别留意有没有不小心提交的无关文件比如编译产物、锁文件乱改动。这一步相当于你提交到公开 review 前的最后一道自查关卡。第二看 GitHub Actions 是否跑起来了。现在主流开源项目都配置了 CI你的 PR 刚提交云端会自动跑 lint、测试、构建。如果红色 ✗ 出现了别等维护者来催自己先去看构建日志修好它。我对维护者催 CI 这件事特别有执念一个 CI 挂掉的 PR就等于在跟维护者说我连验证都没做对方的信任度会立刻打折。5. PR描述怎么写才专业结构与模板代码已经上去了维护者会点开你的 PR首先看到的就是标题和描述。现实中大量 PR 的描述都是空白或者只有一句话这其实浪费了最好的沟通机会。一个合格的 PR 描述应该让维护者不点开代码也能大致判断你的改动。5.1 维护者最想知道的四件事我将自己在 review PR 时的内心诉求做了一个总结输出为一套 PR 描述应该回答的问题问题意思这个 PR 做了什么改动内容的一句话概述为什么需要这个改动修复了什么 bug、满足什么需求怎么验证的跑过什么测试、手动测试过什么有什么潜在影响是否会破坏现有功能、涉及哪些模块如果你能把四件事写清楚维护者的 80% 疑问都在描述里解决了剩下的只需要看代码确认。这就是所谓的替对方着想。5.2 一个可以直接抄的 PR 模板很多成熟项目会在.github/PULL_REQUEST_TEMPLATE.md里提供自己的 PR 模板你提 PR 时会自动带入。但如果没有你可以参照我常用的这套结构## 概述 修复了登录模块中 token 刷新存在竞态条件的问题。 ## 改动内容 - 将 token 刷新过程改为通过互斥队列串行执行 - 补充了并发刷新场景下的单元测试 ## 验证方式 - 本地运行 npm test全部 128 个测试通过 - 模拟 10 个并发请求刷新 token未再出现重复刷新问题 ## 影响的模块 - src/auth/tokenManager.ts - tests/auth/tokenManager.test.ts ## 关联 issue Closes #1024注意其中关联 issue这一项的重要性。GitHub 支持在描述里写Closes #编号PR 合并后会自动关闭对应 issue。这个机制能让项目追踪某个 issue 是被哪个 PR 解决的维护者非常看重。如果你的 PR 是对某个 issue 的回应一定记得写上。5.3 截图和演示胜过一千行文字对于前端项目、UI 改动或者涉及交互的功能描述里贴截图或者 GIF 动图是极大的加分项。GitHub 支持直接把图片拖拽进描述框会自动上传。我在审查一个 CSS 改动的 PR 时如果对方贴了修改前后对比截图我基本不需要再花时间自己起项目去验证样式反之没有截图的话我只能 pull 下来跑一遍成本高出不少。测试结果的汇总也可以用简洁的方式展示。比如表格| 检查项 | 结果 | |--------|------| | 单元测试 | 128 passed | | E2E 测试 | 16 passed | | ESLint | 0 error | | 构建 | 成功 |格式不重要表达我验证过了这个信息最重要。5.4 标题的几个禁忌最后提醒一下标题的坑。不要让 PR 标题变成另一个简短的问题描述比如 fix bug、update这跟空描述没啥区别。标题推荐格式就是 commit message 的主体部分比如feat(checkout): add promo code supportfix(login): prevent redirect loop when session expiresdocs: clarify installation steps for Windows这种标题里带的feat、fix等前缀跟你的 commit 规范呼应保持一致性后项目的 PR 列表整体看起来会非常专业。有些项目甚至会在合并时用这些前缀自动生成 changelog版本更新记录所以标题写规范是实打实有价值的。6. 收到Review反馈之后更新PR的规范姿势PR 提交后你可能会收到维护者的 comments也可能有其他贡献者在你的 PR 下展开讨论。这个过程不可怕被要求修改太正常了。我提了这么多 PR几乎没有一次是一次通过的。真正重要的是收到反馈之后你的应对方式是否规范。6.1 先理解再动手收到 review 意见后我的习惯是通读全部评论区分出三类必须改的比如逻辑错误、风格不合规、测试不过。可讨论的比如我觉得这个命名更容易理解这时候可以礼貌回复自己的理由也可以选择接受对方建议。纯夸奖/锦上添花的比如 Great work!适当回应即可。如果是可讨论的我建议至少先给出一个回应说明你的思路和原因而不是默默按对方说的改完——那样看起来好像是我迫不得已才改。当然如果对方说得合理接受建议并说一句 Good point, updated. 是非常得体的沟通。6.2 更新分支的两种姿势新增 commit vs 改写历史这是 PR 更新环节最核心的一个抉择你的新修改是直接叠加一个新的 commit还是把原来的 commit 全部改写重组如果在 PR 的早期阶段维护者还在做整体逻辑 review建议直接新增一个 commit 来响应修改意见。原因很简单新的 commit 让维护者能清楚地看到从上一个版本到你最新版本之间改了哪些东西——GitHub 的更新 diff 就是基于这个对比的。如果你把历史 rewrite 得干干净净对方反而看不出你响应改动的过程。如果在 PR 已经基本 review 完成、只差几个小问题时可以走 rebase 把历史整理得干净一些再推进。常见做法是把所有响应性的小修改 squash 进对应的原始 commit让最终合并时的历史没有一堆 fix review comment 之类的碎提交。如果是自己本地独享的分支推荐用 rebase 流程统一整理。以把最近三个 commit 合并成一个为例git rebase -i HEAD~3在弹出的编辑器里将后两个pick改成ssquash保存然后在第二个界面上统一写一份完整的提交信息。完成后如果你已经 push 过旧版本就需要用强推来更新远程分支git push --force-with-lease origin fix/docs-typo6.3 force push 的正确打开方式git push --force是危险操作但有时候没法避免。这里我强烈推荐使用--force-with-lease而不是直接--force。区别在于--force无条件覆盖远程分支--force-with-lease会先检查远程分支是否和你本地记录的一致如果不一致说明别人可能已经推了新代码它就拒绝执行。这是保护队友最后一根稻草也能避免把协作伙伴的提交整消失。需要强调一个常见误区如果 PR 分支是你和另外一个人共用的比如你们一个负责实现、一个负责测试共用同一 fork 分支改写历史 force push 很容易把另一个人的提交冲掉。这种协作场景下尽量用新增 commit 的方式来更新不要频繁改写历史。6.4 在 GitHub 上逐条回复评论在评论区对每一条 review 意见做简要回复是一个非常良性的沟通动作。哪怕只是 Done. 或在代码里说明已修复位置维护者也会觉得你认真对待了反馈。GitHub 的 review 评论如果被回复会进入已解决/待解决的状态流转方便对方二次审查。另外我建议在把所有修改 push 上去后在 PR 里追加一条总括性的评论比如刚刚根据 review 意见做了 N 处调整主要集中在 X 和 Y测试已全部通过麻烦再 review 一下。这样维护者会主动回来看更新。不回应、不评论地默默 push对方可能根本不知道你已经改了。6.5 冲突来了怎么办如果你的 PR 存在合并冲突GitHub 页面会显示红色 This branch has conflicts that must be resolved。处理流程也很标准git checkout fix/docs-typo git fetch upstream git rebase upstream/mainrebase 过程中 Git 会标记冲突文件你手动解决后git add 冲突解决后的文件 git rebase --continue完成后测试验证然后强推更新 PR 分支。整个过程在本地操作即可GitHub 上那个红字不用等它自己消失它会在你的分支更新后自动重新计算合并状态。7. 我踩过的那些PR坑真实案例与避坑清单最后一部分我不打算再讲流程而是给你一份我亲手踩过、也亲眼见过别人踩过的 PR 避坑清单。每一条都是真实教训不看流程正规但看这些坑能少走很多弯路。7.1 默认分支上直接开改我认识的一位朋友第一次给开源项目贡献时图省事没开分支直接在 clone 下来的 master 上改了代码然后 push 到了他自己 fork 的 master又把这个分支和原仓库的 master 去比对创建 PR。结果就是 PR 里出现了大量不相关的历史差异因为他的 master 落后了原仓库几百个 commitGitHub 无法正确计算 diff。最后他只能把 fork 删了重新来一遍白费了一个下午。正确做法永远是在干净的 master/main 基础上拉一个独立的功能分支。我之前在 2.3 节讲的那个流程就是从这一类惨痛教训里总结出来的。7.2 忘掉同步 upstream导致大量冲突我有个习惯是提 PR 前一定会做一次git fetch upstream确认自己的分支不是落后状态。曾经有一次我没有同步交上去的 PR 涉及到一个文件而那个文件上游已经重构过三轮了。review 时维护者很客气地让我解决冲突我本地却因为缺少最新的上游代码处理得痛苦万分。同步不是一次就够。你的 PR 周期拖得越长越要记得时常git fetch upstream git rebase upstream/main。把这个动作当作一个常规步骤而不是出问题时的急救手段。7.3 把review 修改压成乱麻还有一种情况很常见你反复提交了十几个 commit 来回应 review 意见历史看起来像这样fix comment 1、fix comment 2、add missing import、oops forgot this。这类碎提交会让 final 合并时的历史极其难看。如果你和协作者没有共用分支建议在 PR 接近完成时做一次 squash 整理把全部改动整合成一两个干净的 commit。本地上操作是git rebase -i origin/main进入交互模式把所有提交按需合并然后git push --force-with-lease。整理完之后再看 PR 的 Files changed等于是一个全新的、聚焦的 diff。7.4 PR 里混入了与主题无关的改动我 review 过一个修复登录 bug的 PR结果 diff 里除了登录模块还顺带把整个项目的代码格式化了一遍、升级了依赖版本、调整了两个 CSS 变量。不能说那些改动是错的但它们和 PR 主题完全无关导致我无法判断哪些改动会影响登录行为。正确做法是无关改动要么拆成单独 PR要么干脆先不动提 issue 告诉维护者。如果你只是帮忙修了一个旁边的 typo可以顺便但牵扯到格式化、重构、依赖升级这类大规模改动一定要分开。PR 越小review 越快被合并的概率越高。这一条怎么强调都不过分。7.5 测试没跑就提交这个坑我已经提过多次但因为它太重要了还是放在避坑清单里压轴。我犯过一次最蠢的错误改了一个配置文件的路径本地没生效验证直接 push 提 PR结果 CI 构建直接挂掉。维护者找我说 Build is broken我只能马上修、重新推整个过程极其尴尬。我的建议是在推送之前固定跑三件事git status看文件改动是否正常、相关测试命令npm test或项目文档里的命令、lint 命令如果有。如果你改了文档或者纯注释至少也要git diff检查一下格式。让 CI 挂掉是比代码写得烂更让人对你的判断力失去信心的信号。7.6 把 issue 和 PR 的关系写清楚还有一个小建议如果这个 PR 是为了解决某个 issue在 PR 描述里写Closes #123会非常方便后续追踪。很多人知道这个语法但在描述里写了个寂寞维护者还得手动去关联。这种举手之劳的事情做到位了你的贡献会显得格外上心。我从第一次提 PR 的懵懂到现在偶尔review别人的PR最深的感受是**规范的 PR 流程不是束缚而是一种互相尊重。**你尊重维护者的时间他们也会更尊重你的劳动。把这篇文章里讲的流程走一遍你的第一个 PR 或者下一个 PR体验一定会完全不一样。