如何成为开源贡献者？
如何成为开源贡献者？
大家好，我是二哥呀。这里收录一篇星球嘉宾阿杆关于《如何参与一个开源项目》的帖
子，也是因为星球里有球友提问，想参与到开源项目当中，但不知道怎么做贡献。
说起开源项目，好像人人都懂：不过就是一群人一起写了些东西，并且这些东西是公开
的，大家都能看。但要细说，可能大多数的开发者都说不出个所以然，甚至不知道怎么提
issue。
这篇帖子就来聊聊，我是如何参与开源项目的，参与开源项目的正确流程是怎样的，以及
我们参与开源项目的意义。
本篇帖子适合的球友：
• 有一定的 Git 基础，会 commit pull push、会解决合并冲突、知道仓库和分支的概
念，没有的可以参照这篇帖子：1 小时彻底掌握 Git
• 对 GitHub 有一定的了解，像二哥的 Java 进阶之路和技术派都是托管在 GitHub 上
的。
第零步：为何参与开源项目
作为一名程序员，我想大多数球友应该都和我一样，在编程方面主要靠自学，比如看书、
看视频或看博文。
但当我们学习到一定程度的时候，总该把自己所学的东西融会贯通一下。这时候我们就会
去试着写一些代码，做一做项目。
而聪明的开发人员会意识到那些有长期积累经验的开源项目当中蕴含着大量的知识，可以
从优秀开源项目的代码当中学习到相当多的东西。
如果恰好有兴趣且恰好有时间，参与开源项目将会是提升自我的好机会，你的代码将会经
过一双双眼睛的审查，你将得到其他程序员的建议，这在无形之中便能提升你的代码质量
和规范。
目。
? 项目，
型一 般 都 是 比 的
尤其是作学生，在校能接触到的目一般都是比
大
企
至
甚
目
向
方
种
各
到
触
接
以
你
区
社
源
开
在
但
）
不
得
己
自
能
可
（
的
之
生
学
、
系
理
管
似 较简单的 ， 类似 图书管 理 系 统、 学 生 选课系 统之 类的 （ 可 能 自 己 觉得 不 简单 ? ） ，
总之，可以确信的是，参与到一个合适的开源项目中，一定是对你有较大帮助的。
欢迎大家参与我的开源项目校园博客，这是一个基于 SpringCloud + Vue2 的微服
目，后端主要由我负
项
务 ，原来的前端开发
责 者忙着考公去了（果然人生的尽头 是编
还 制），所以现 在非常期待前端大
。
第一步：提出问题
我们在写代码之前，总得想想自己要写些什么东西，总不能上去就是一句 “Hello world”
吧！
那我们要参与一个开源项目，是不是也得想想自己该为这个项目贡献一些什么功能？
这时候，我们需要先了解这个项目。就拿我的校园博客来说，我们可以先去项目网站进行
使用体验，找到一些 bug 或者还没有完善的地方，再或者找到一些可以新添加的功能，
那么这些就是我们要提出的问题了。
①、于是乎，我们去给项目提一个 issue，并根据社区的提问要求，将自己的想法用
issue 来告诉项目负责人。
640
②、写好标题和内容后，点击右下角 Submit new issue，你就能看到自己创建的一个
issue 了，那么恭喜你，已经为这个社区贡献出了自己的一份力量，尽管这只是一个
issue！
640
③、提出问题，其实也可以是寻找问题。有些时候，我们可能无法轻易的找到项目的
bug，也没有什么好的建议，这时候，我们也可以直接去查看社区里已经存在的 issue。
下面这些其实都是别人已经提出的问题，可以在里面找一个我们想做的并且还没有被分配
的，一般建议新人贡献者找那种带有 good first issue 标签的问题，这类问题更适合提供
给新同学作为加入开源项目的第一个贡献，因为它们相对较简单。
640
④、那不管怎么样，我们现在至少创建或者找到了一个合适的 issue。现在，我们去这条
issue 的评论区发送一句话，表示自己想认领并解决这个问题，就像这样：
640
⑤、接下来，我们只需要等待社区的管理员回复你。如果他同意了你的 issue 并且觉得你
可以解决这个问题，他会回复你的评论，并且将这个问题分配给你，就像这样：
640
第二步：Fork 仓库
是时候开始进行项目的开发了！可是我们应该把代码写在哪里呢？
直接把代码下载下来，然后在本地开始写代码，写完代码再通过社交软件发送给项目的管
理人员吗？当然不是，这一点都不 Git。
我们应该先将原仓库 Fork 到自己的仓库里（在项目首页的右上角），相当于把这个仓库
**深拷贝**一份到我们自己的仓库里。因为这样我们才有编辑的权限，写完代码以后才能
将代码提交到 GitHub 上：
640
点击 Create fork 即可
640
Fork 成功之后，在我们自己的仓库里就会有一份与原仓库一样的仓库，并且这个仓库是
我们自己的，这意味着我们可以在这个仓库里进行任意的代码更改，But 原仓库我们仍然
是没有权限的。
所以我们将来编写代码的时候，就是在这个仓库上进行操作的。
现在我们将代码拉取到本地，我比较喜欢使用 idea 进行 git 操作，这个 url 记得用自己仓
库的 url：
640
保证分支仓库和主仓库同步
仓库 Fork 以后，会出现一个新的问题：原仓库会有人更新代码，但我们的仓库不会被自
动更新，就会导致两个仓库的进度不一致，将来提交 PR 的时候就可能会造成合并冲突。
所以我们每次写代码和提交代码之前，最好都要先去同步一下我们的仓库。
（1）在 GitHub 上进行同步
点击分支仓库的 Sync fork 按钮，可以对分支进行更新操作：
640
（2）在 GitHub 桌面版上进行同步
这是二哥一直在用的方法，对新手更友好，不用记命令，点点鼠标就可以了。
86330ab9-8dee-4337-808c-27bc85f57862.png
（3）在 idea 上进行同步
有时候我们使用方法一解决冲突可能会比较麻烦，因为在网页上操作没有那么方便，所以
我更建议大家使用这个方法三。
①、首先在本地 git 仓库中添加多个远程仓库，右键点击远程，然后会弹出一个管理远
程，点进去就可以配置远程仓库了
640
这是我配置好的远程仓库，第一个 main 是源项目的仓库，第二个 mine 是
我
自己
的（
我
用来演示的账号名就叫 scblogs），我给他们分别取了对应含义的名称：
640
然后我们点左边的 fetch 刷新一下，就可以看到有两个远程了：
640
②、当我们要准备写代码和提交代码之前，先 fetch 一下远程仓库，看看网络图，主仓库
里有没有更新些什么东西
640
我们发现远程的主仓库的 main 分支已经超过了当前我的分支（那个黄色的标记就是本地
的当前分支），两个仓库不一致的时候（看不清可以放大），那我们就要及时的去拉取主
仓库 main 分支的代码，将自己的仓库进行更新。
③、拉取代码的时候选择主仓库的 main 分支，然后点拉取，就会更新合并到本地分支代
码了：
640
更新之后，我们当前分支已经处于最新的版本了：
640
第三步：编写代码
没什么好说的，写代码就好了。
在我们写代码之前，最好先看看项目的贡献者说明，或许我们在参与某项目之前就应该先
看这个。
一般是主目录下的一个叫做 CONTRIBUTING.md 的文件，里面会写一些注意事项，包括
代码规范和编写代码的一些操作、流程、步骤等，仔细阅读这份文档，可以保障我们的更
好的参与项目的贡献。
640
写的过程中如果遇到了疑问，及时向社区提问，以免自己白费一通力气。
一个有活力的社区，一定会有人及时回复你的。不过也要注意提问的内容，有些东西能在
搜索引擎上获得答案的，就不要去打扰别人了。
对了，在你提交代码的时候，最好把每次提交的内容都尽可能的进行细分。
比如，我现在正实现用户排行榜的功能，而用户排行榜又分为了用户活跃排行榜和用户等
级排行榜，那么我应该将它们分成两次提交，且每次提交都只添加跟当前提交描述相关的
代码。又或者，我在实现排行榜功能的过程中，发现了一个之前遗留的 bug，那么我应该
将解决这个 bug 的代码进行单独的一次提交。
这样将提交细分的好处就是，将来管理员要对你的代码进行审查的时候，他将会更清楚的
知道你每行代码的目的，也会更方便于历史提交信息的查询。
然后就是写代码，写完了，commit 提交，然后 push 到自己的仓库上去，如果这时候发现
主仓库的 main 分支有更新的代码，最好也手动同步一下，并将冲突解决。
温馨提示：在提交代码之前，最好先自己对自己的代码进行一次审查，在 idea 的提交界
面，可以很方便的对自己修改过的代码进行审查。审查的过程中注意判断，只提交那些有
意义的代码，有些调试过程中留下的代码，是不应该被提交的：
640
此时我已提交并推送完毕：
640
第四步：创建 PR
到这一步，我们已经准备好将自己写的代码提交到主仓库了，但由于我们没有主仓库的操
作权限，所以是无法直接提交到主仓库的。
这时，我们需要创建一个 Pull Request （俗称 PR），意思是请求主仓库的所有者从你的
仓库中拉取代码合并到主仓库中。
如何写描述信息
还记得我们之前创建或者认领的那个 issue 吗，如果我们此时要提交的代码已经解决了这
issue 所涉及的问题，那我们就可以在 PR 当中把这个 issue 关闭了，只需要在我们等会
个
要填写的描述信息里加上 “close #78” 就可以了，78 指的是那个 issue 的编号，可以在它
的页面上看到：
640
当然，PR 的描述信息里不能只有个 close，否则会让项目负责人很抓狂，因为他无法确
定你写的代码是否能够达到预期的效果，甚至他可能还得去自己进行一次测试。
所以正常的描述信息，应该包含这个 PR 解决了什么问题、如何解决的、以及新增代码的
测试效果截图。
测试截图很重要，我们截图之后是可以直接粘贴到 github 的描述信息里的，非常方便，
但这几张图片却可以让负责人对你的代码更放心。
关于如何发起 PR，我们可以在 GitHub 的页面上进行操作，也可以在 idea 上进行操作，
我个人更喜欢在 idea 上操作。下面我将分别介绍这两种方式。
（1）在 GitHub 上发起 PR
①、 进入到我们的仓库主页，可以看到上面提示说我们的分支领先于主仓库的 main 分
支：
640
②、点击 Contribute，然后点击 Open pull request：
640
③、此时系统会自动帮我们跳转到创建 PR 的页面，填写完提交信息，指定从哪里合并到
哪里（一般是选择从我们自己仓库的 main 分支合并到主仓库的 dev 分支），点击 Create
pull request 即可：
640
（2）在 idea 上发起 PR
PS：这是由 GitHub 插件提供的功能，只支持 GitHub 的 PR 管理。
①、找到并打开 视图 -> 工具窗口 -> 拉取请求：
640
②、这里选择主仓库，因为我们是要对主仓库发起 PR，然后点击查看拉取请求：
640
③、点击设置旁边的加号，开启一个新的 PR：
640
④、指定从自己仓库的 main 分支合并到主仓库的 dev 分支，填写标题和描述，点击创建
拉取请求即可：
640
第五步：代码审查
当项目管理员收到你提交的 PR 后，他会对你提交的代码进行审查。
说白了就是查看你写的代码，并考虑其中写的好的和写的不好的地方，然后给你提出意见
和建议。
作为贡献者，我们需要根据管理员的意见进行代码的修改，或者（跟他掰扯掰扯）跟管理
员解释我们为什么要这样写，这样写的目的是什么，总之，你们两协商并达成一致就可以
了。
那当我们修改完代码后，再提交到自己的仓库中 之前用来创建 PR 的那个分支，之前创建
的 PR 就会被自动更新了，不需要我们再开启一个 PR（除非之前的 PR 被关闭了）。
那如果我们的代码通过了审查，它就会被合并到主仓库中，这时候我们的一次代码贡献就
算是完成啦！你会被列在项目的贡献者列表中，就像这样：
640
写在文末的一些话
? 会想源
。， 加
看完套流程，可能多朋友想，
了
加
不
是
我
那
，
麻
目 ?
参加 开源 项目 咋这么麻 烦， 那 我 还是 不 参加 了 ? ? 。
?内容也得麻，了我好天可能是因的太哈。的 候时候 也 觉得 麻 烦， 咋这么难写， 写了 我 好 几天 ， 可 能 是 因 为我 写的 太 详细了 ， 哈 哈 哈 哈 哈 哈 哈 ? 。
我篇容的
但平时我参与项目贡献的时候，其实并没有觉得有什么麻烦的地方，也就是点几下点几
下，很快就搞定了，时间主要都花费在了提问、沟通和写代码上，并没有在这些“杂七杂
八”的流程上浪费什么时间。而且这套流程中有几步其实是只要做一次的，真正需要每次
都操作的，其实只有写代码、创建 PR 和同步仓库。
后
再
想去
参加
各
种
说呢 ， 自 己 尝试一 下 ， 把 这套 流 程 操 作 一 遍 ， 或 者 去 参 加 一 个 开 源 项目 （ 欢迎 来 校园博客 ）
怎么呢，自己一下，把套流程操作一遍，或者去参加一个开源目（迎来
开
源目，
至少
流
程都
了。
，
自己
从到尾操作一遍之后，就没什么?
头到尾操作一遍之后，就没什么问题了，以
了，以
对了，如果你看了这篇内容之后还想了解得更多，可以再看看这位作者的文章，我觉得写
得挺好的，分享给大家：如何参与开源项目 - 细说 GitHub 上的 PR 全过程
如果这篇内容对你有帮助，那就赶快去找个合适的开源项目试一试吧！从实践中去练习这
些步骤，会让你对它的理解更加深刻噢！