如何参与开源项目 - 细说 GitHub 上的 PR 全过程

本文链接：https://blog.csdn.net/farmer_hutao/article/details/125652598

本文详细介绍了如何参与 GitHub 上的开源项目，从寻找合适的项目和贡献点，到 PR（Pull Request）的全过程，包括 Fork 项目、克隆到本地、更新代码、提交 PR，以及解决冲突、修正 CI 错误等问题。通过实例讲解了如何在开源社区中提升编码能力，降低参与门槛。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一、概述

今天我准备和你详细介绍如何开始参与开源项目，帮助你在 GitHub 上完成第一个 PR 的合入。

当然，除了正常的 PR 合入流程之外，我还准备详细介绍一下如果一个 PR 提交后遇到了冲突、需要追加 commits、需要合并 commits 等等相对复杂问题该如何解决。

总的来说，本文计划分为4个部分：

谈谈为什么要参与开源项目以及我为什么要介绍如何 PR
谈谈怎么开始参与开源项目，也就是如何寻找合适的开源项目、如何寻找贡献点
介绍怎么上手 PR 流程，即从 fork 到 push 全流程
介绍提交了 PR 之后遇到各种常见问题如何解决

Ok, let’s get started!

二、为什么要参与开源项目

本文我不打算长篇大论“为什么要参与开源”，详细介绍参与开源项目的收获，我想仅从“提升编码能力”角度谈一谈“为什么要参与开源项目”。

在面试的时候我有个习惯，如果候选人在自己的简历里说到自己熟悉某一门语言，我就会习惯性问他一个问题：

你有没有阅读过某个开源项目的源码？或者更进一步，有没有参与过某个开源社区，或者说给开源项目提过 PR？

如果答案是肯定的，比如候选人说自己读过部分 Kubernetes 模块的源码，再进一步我确认他真的读过并且读懂了或者说真的提交过 bugfix/feature 类型的 PR，那我就不再问编程语言层面的问题了，因为我相信能看懂一个成熟的开源项目部分模块源码或者能够提交 bugfix/feature 类型的 PR 已经说明了一切。

我自己在学习 Golang 的时候，大致分为两个阶段：

学习基础语法，开始写项目，直到能够熟练完成各种业务功能的开发；
看了一些开源项目的源码，深感受益颇多，编码水平再上一个台阶。

差不多也就是在看 Kubernetes 项目源码的时候，我深刻认识到一般的企业内部项目和汇集全世界最优秀的程序员智慧结晶的开源项目之间的巨大差距，也意识到学习优秀开源项目源码对于一个程序员编码水平提升的重要性（当然，你可以说 Google 内部也存在非开源的非常优秀的代码，这毫无疑问，但是我想今天我们没有必要讨论特例）。

认真阅读开源项目源码，你总会发现一些小瑕疵，这时候提一个 PR(Pull Request)，让你的代码合入开源项目，运行在“世界每一个角落”，那是多么有趣的事情！而成功合入第一个 PR 往往就像打开潘多拉魔盒一样，你会进入到另外一个世界，开始接触到开源社区，感受开源的魅力！

三、为什么我想介绍如何 PR

我司开源了2个项目，分别是：

CNCF Project DevStream

CNCF Project DevStream

Apache DevLake

DevStream 项目和 DevLake 项目隔三差五就会有新贡献者提交 PR 过来，但是多数贡献者在提交第一个 PR 时往往会遇到一个或多个问题，比如产生冲突、commits 记录过多或者混乱、commit 没有签名、commit message 不规范、各种 ci 流程检查报错等等。

在看到新贡献者提交 PR 时，我们自然是非常开心且热情地对他表示欢迎并且告知如何修复各种问题，但是随着贡献者的增多，我们的开源社区几乎每天都需要回答一个问题：“如何正确地提交一个 PR”。可能此时你会开始怀疑我们是不是没有提供相应的文档？其实不然，我们有详细的文档，但是人总是有惰性的，多数的新贡献者并没有足够的意愿去仔细看翻看文档然后再提交 PR，甚至很多新贡献者由于刚开始接触开源项目，对于项目结构和文档组织结构比较陌生，甚至不会想到有这些文档的存在，总之各种各样的理由让多数的新贡献者会选择“先提了 PR再说”。

那么今天我想尝试彻底讲明白“如何正确地提交一个 PR”，尝试细说 GitHub 上的 PR 全过程，以及这里面可能会遇到的各种困难和解决办法。一方面希望对第一次参与开源项目的新人有所帮助，另一方面希望能够进一步降低 DevStream 社区和 DevLake 社区的参与门槛。

四、我想参与开源项目，怎么开始？

不管你为什么决定开始参与开源项目，不管出发点是出于学习、兴趣、成就感等等，还是为了让某个自己需要的特性合入某个开源项目，总之今天你下定决心，要给某个开源项目提交一个 PR 了，好，我们开始吧！

4.1、寻找一个合适的开源项目

如果你已经决定参与某个开源社区了，那么请直接跳过本小节。

如果你就只是想开始参与开源，暂时还不知道该参与哪个社区，那么我有几个小建议：

不要从特别成熟的项目开始。比如现在去参与 Kubernetes 社区，一方面由于贡献者太多，很难抢到一个入门级的 issue 来开始第一个 PR；另外一方面也由于贡献者太多，你的声音会被淹没，社区维护者并不在意多你一个或者少你一个（当然可能没有人会承认，但是你不得不信），如果你提个 PR 都遇到了各种问题还不能自己独立解决，那么很可能你的 PR 会直接超时关闭，没有人在意你是不是有一个好的参与体验；
不要从特别小的项目开始。这就不需要我解释了吧？很早期的开源项目可能面临着非常多的问题，比如代码不规范、协作流程不规范、重构频繁且不是 issue 驱动的，让外部参与者无所适从……
选择知名开源软件基金会的孵化项目，这类项目一方面不是特别成熟，所以对新贡献者友好；另一方面也不会特别不成熟，不至于给人很差的参与体验，比如 Apache 基金会、Linux 基金会、CNCF 等。

比如可以从这些地方寻找自己感兴趣的开源项目：

当然，你也可以直接选择从 CNCF 沙箱项目 DevStream 或者 Apache 孵化项目 Apache DevLake，以此敲开开源世界的大门。

4.2、寻找贡献点

开源项目的参与方式很多，最典型的方式是提交一个特性开发或者 bug 修复相关的 PR，但是其实文档完善、测试用例完善、bug 反馈等等也都是非常有价值的贡献。不过本文还是从需要提 PR 的贡献点开始上手，以 DevStream 项目为例（其他项目也一样），在项目 GitHub 代码库首页都会有一个 Issues 入口，这里会记录项目目前已知的 bug、proposal(可以理解成新需求)、计划补充的文档、亟需完善的 UT 等等，如下图：

DevStream Issues