我的第一次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,用了错误的代码格式。
第三步:设置开发环境 必须做的:
Fork项目仓库 Clone你的Fork到本地 创建新的分支(不要在主分支上直接改) 安装所有开发依赖(包括linting、测试工具) 运行现有测试,确保全部通过 分支命名规范:
fix/typo-readme(修复文档) feat/add-new-test(添加新功能) docs/update-install-guide(文档更新) 第四步:写代码——但别只写代码 同时要做的事:
遵循项目的代码风格(使用项目的linting工具) 写测试(如果项目有测试要求) 更新相关文档(如果API有变化) 保持改动最小化(只改必要的部分,不要"顺便"重构) 代码审查者最讨厌的事: 一个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.”
...