给开源项目提 PR（Pull Request），是很多程序员的"成人礼"。流程本身不复杂，复杂的是第一次的心理门槛：怕改错、怕被拒、怕被人笑话。这篇把全流程拆开，照着做就行——其实维护者们欢迎新人 far more than 你想象的。

先选对项目

第一个 PR 别去挑战巨型项目。好的起点有三种：

  • 改文档：你平时在用的工具，发现了错别字、过时的截图、翻译问题——改文档是最好的第一次，风险为零，还能熟悉全流程。
  • 找 good first issue：这是维护者专门留给新人的标签，难度经过筛选，适合练手。
  • 中小型项目：维护者响应快，你的 PR 不会石沉大海，互动体验好得多。

全流程六步

1. Fork：点仓库右上角的 Fork，把项目复制到你自己名下。这一步是你和原仓库建立关系的起点。

2. Clone 到本地：git clone 你 Fork 后的地址（注意是你的地址，不是原仓库的），把代码拉到本地。

3. 建分支：git checkout -b fix-typo，分支名起得见名知意。别直接在 main 上改，这是基本礼仪——保持 main 干净，review 的人才看得清楚你改了什么。

4. 改代码并提交：改完后 git add + git commit，commit 信息写清楚改了什么，比如 fix: correct typo in README。好的 commit 信息是专业素养的体现。

5. Push 并提 PR：push 到你 Fork 的仓库，回到 GitHub 页面，它会提示你发起 Pull Request。PR 描述别只写"fix bug"，用这个模板：

改了什么：…… 为什么改：…… 怎么验证：……

6. 等待 review：维护者可能会提修改意见，照着改、push，PR 会自动更新。合并后你的名字就出现在贡献者名单里了。

新人礼仪和避坑

  • 先读 CONTRIBUTING：很多仓库根目录有 CONTRIBUTING.md，写了代码规范和 PR 要求。不读就提 PR，很容易因为格式问题被打回，白白多一轮。
  • 一次 PR 只做一件事：别把修 bug、改格式、加功能混在一个 PR 里。小的、聚焦的 PR 通过率最高。
  • 别催：维护者都是志愿者，PR 几天没动静很正常。超过两周可以礼貌地 ping 一下，语气客气点。
  • 接受批评：review 意见是针对代码不是针对人。照着改就是了，这是成长最快的方式，没有之一。
  • 被拒了别灰心：PR 被拒绝太正常了，可能是方向不对、时机不对。问清楚原因，改一版或者换个 issue，大把机会。

PR 合并之后

PR 被合并了，别急着关页面，还有两件事：

  • 删掉你的分支：GitHub 会提示删除，点一下就行。留着一堆旧分支，以后自己都分不清。
  • 同步上游更新：你的 Fork 和原仓库从此就分叉了。以后想继续贡献，先把原仓库的新提交同步过来（git pull upstream main），再开新分支。很多新手第二次提 PR 时带上了一堆旧提交，就是没做这一步。

另外，你的 GitHub 主页会出现贡献记录的小绿格，第一个 PR 的那一格，值得截图留念。

从哪里开始找项目

除了 good first issue 标签，也可以在 GitHub 搜索 label:"good first issue" language:python（换成你的语言）找机会。之前写的《GitHub 高级搜索》里的筛选语法，这里正好用上。

第一个 PR 的意义不在于改了多少代码，而在于走通了"参与开源"这个流程。走通一次，后面就顺了。很多人都是从改一个错别字开始，几年后成了核心维护者。