我的第一次PR：被拒绝了7次

2025年，我第一次给一个知名大模型开源项目提PR（Pull Request）。我信心满满——我修复了一个bug，写了测试，觉得自己做得很好。

结果呢？被拒绝了。不是一次，是七次。

第一次被拒：代码格式不符合项目规范。第二次被拒：没有签署CLA（贡献者许可协议）。第三次被拒：测试用例不够。第四次被拒：commit message格式不对。第五次被拒：没有更新文档。第六次被拒：代码审查意见没有全部回复。第七次被拒：代码冲突。

七次被拒后，我几乎要放弃了。但第八次，我的PR终于被合并了。

现在，我已经为多个大模型开源项目贡献了代码。这篇文章是我用七次被拒换来的经验，希望帮你少走弯路。

第一步：选择你的第一个PR

不要做这些：

  • 不要一上来就提一个大的功能改动
  • 不要修改核心算法
  • 不要重构代码架构

要做的：

  • 修复文档中的拼写错误或过时信息
  • 为某个函数添加缺失的docstring
  • 修复一个标记为"good first issue"的bug
  • 优化某个测试用例的性能

数据： 开源项目中，标记为"good first issue"的PR，合并率超过80%。而大的功能改动PR，合并率不到30%。

第二步：阅读CONTRIBUTING.md

这是最容易被跳过的步骤，也是最重要的步骤。一个项目的CONTRIBUTING.md通常会告诉你：

  • 如何设置开发环境
  • 代码风格要求（如缩进、命名规范、linting规则）
  • commit message格式
  • 是否要求签署CLA
  • PR模板
  • 测试要求

我所犯的错： 第一次PR被拒，就是因为我没读CONTRIBUTING.md，用了错误的代码格式。

第三步：设置开发环境

必须做的：

  1. Fork项目仓库
  2. Clone你的Fork到本地
  3. 创建新的分支（不要在主分支上直接改）
  4. 安装所有开发依赖（包括linting、测试工具）
  5. 运行现有测试，确保全部通过

分支命名规范：

  • fix/typo-readme（修复文档）
  • feat/add-new-test（添加新功能）
  • docs/update-install-guide（文档更新）

第四步：写代码——但别只写代码

同时要做的事：

  1. 遵循项目的代码风格（使用项目的linting工具）
  2. 写测试（如果项目有测试要求）
  3. 更新相关文档（如果API有变化）
  4. 保持改动最小化（只改必要的部分，不要"顺便"重构）

代码审查者最讨厌的事： 一个PR包含了三个不相关的改动。每一个PR应该只做一件事。

第五步：提交commit

commit message格式：

大多数项目遵循Conventional Commits规范：

<type>(<scope>): <short summary>

<longer description>

<footer>

示例：

fix(dataloader): handle empty batch in distributed training

When the dataset size is not divisible by the number of workers,
the last batch might be empty, causing a runtime error. This fix
adds a check for empty batches and skips them.

Fixes #1234

我做错的事： 第一次提交时，commit message是"fixed bug"。审查者回复：“What bug? Please be specific.”

第六步：创建PR

PR模板：

大多数项目都有PR模板。认真填写：

  1. 描述： 清楚说明你做了什么改变，为什么需要这个改变
  2. 关联Issue： 如果有关联的Issue，一定要引用
  3. 测试： 说明你做了哪些测试
  4. 截图： 如果修改了UI或有可视化的变化，附上截图

PR标题： 使用和commit message相同的格式。

第七步：处理代码审查

审查者会看什么：

  • 代码是否正确
  • 代码风格是否符合规范
  • 是否有测试
  • 是否有文档更新
  • 改动是否最小化
  • 是否有潜在的性能问题

如何处理审查意见：

  1. 认真对待每条意见，即使你不同意
  2. 如果不同意，礼貌地解释你的理由
  3. 不要因为被提了意见就沮丧——审查是正常的
  4. 及时回复和修复，不要让PR长时间处于停滞状态

数据： PR在24小时内回复审查意见的，合并率比超过48小时才回复的高出40%。

第八步：等待合并

保持耐心。大模型项目的维护者通常很忙，PR可能需要几天甚至几周才能被合并。你可以在PR中礼貌地询问进度，但不要过于频繁地催促。

避坑清单

  1. 不要跳过CONTRIBUTING.md
  2. 不要在一个PR中做多个不相关的改动
  3. 不要忘记签CLA（如果项目要求）
  4. 不要忘记写测试
  5. 不要忘记更新文档
  6. 不要用模糊的commit message
  7. 不要忽略代码审查意见
  8. 不要频繁催促合并

写在最后

给开源项目贡献代码，不只是为了"把代码合并进去"。它是一次学习的机会——学习大型项目的代码架构、工程规范、协作流程。即使你的PR被拒绝了，你也学到了东西。

我的七次被拒教会了我比任何课程都多的软件工程实践。现在回头看，那些被拒是我成长最快的时刻。

你第一次给开源项目提PR的经历是怎样的？评论区分享你的故事。