如何参与开源项目

 关注

发布于: 2020 年 05 月 22 日

前言﻿
这篇文章的起因是朋友的一个疑问：如何参与开源项目？搜索了一下网上类似的文章，大多都是讲解如何操作 GitHub 来给开源项目贡献代码、开源协议有哪些以及开源项目的一些介绍。而开源项目作为开源思想的产物，最难的从来都不是贡献代码，而参与的方式也不只有贡献代码一种（虽然贡献代码是最直接的）。下面就根据我的经验，介绍一下如何参与到开源项目中。
心理建设﻿
在和不同的小伙伴聊过之后，发现大家都有一个同样的问题：很多同学都觉得参与开源项目是技术大牛的事情，我们这种技术水平一般的，只需学习怎么使用就行了。
那么这就引出了小标题心理建设的重要性，一个开放的项目（伪开源不算），是可以接纳任何可行有益的建议的，只要是对项目有利的贡献，都会得到认可（前提是你能说服别人）。会有一些技术大牛维护这些项目，但不代表任何参与该项目人都是技术大牛，就如之前 4 岁小女孩可以给 Linux 内核贡献提交，只要你的提交可以提升项目质量，哪怕是一个符号的修改都会得到肯定。社区是开放的，任何人都可以参与进来；社区又是严谨的，只要有错误，任何人都可以修改它，并不是“大神”们的专利。
如何开始﻿
开始前，首先要明确你想要做的内容，除了贡献代码以外，bug 的发现、新功能的建议、文档的补充、测试用例的完善，甚至是错别字的纠正，这些都是参与开源项目的方式。正如上文所说，一个开放的社区，是不会拒绝任何可以提升项目质量的行为的。
而代码贡献方面，如果有志于贡献高质量的代码、修复 bug 或贡献新功能，在开始时，可以打开 ISSUE，里面有一些打着 good first issue Label 的 ISSUE，这些 ISSUE 通常会使一些小功能的开发或者 bug 的修复，你可以通过完成这个 ISSUE 来踏出你贡献代码的第一步。当然，在该 ISSUE 中的交流时必不可少的，这样可以帮助你更详细的了解该 ISSUE 要解决的问题，从而在开发中少走弯路。
﻿
good first issue
﻿
贡献规范﻿
每个开源项目都会有自己的贡献指南（Contributing Guidelines），在参与项目之前，请先阅读该指南，一般该指南中都会有诸如 Slack channel 或邮件列表这样的沟通工具的链接，或者钉钉、微信这样即时交流工具的二维码（当然最简单的是在 ISSUE 中交流，并且这也是最直接也最容易得到回复的沟通方式）。
一般来说，不要在 fork 代码的 master 分支上做任何修改，该分支用来和上游代码库保持同步！ 一个开发分支对应一个功能点，并且对应一个 PR，一个 PR 对应一个 ISSUE，最好不要将多个功能写在一个 PR 里，这样会增加项目维护者 review 的难度。
GitHub 操作﻿
下面就是一些在 Github 上的操作规范。
﻿
fork 项目要参与项目贡献，首先需要 fork 项目代码，在项目页面点击 fork 按钮，将其 fork 到自己的仓库中：
﻿
fork 项目
﻿
本地配置在项目 fork 好之后，将其拉取到本地：
$ git clone https://github.com/sunny0826/kubernetes.git
为了保持与上游仓库代码一致，添加上游仓库：
$ git remote add upstream https://github.com/kubernetes/kubernetes.git
上游仓库添加好之后，之后都可以通过以下命令来使本地仓库与上游仓库保持同步：
# 切换分支
$ git checkout master
# 更新上游代码
$ git fetch upstream
# 合并代码到 master 分支
$ git merge upstream/master
# 上传代码
$ git push
﻿
新建开发分支在同步上游仓库之后，就可以新建分支，添加自己的修改了：
$ git checkout -b xxx
﻿
提交 PR在开发完成后，就可以 push 代码，然后提交 PR 了。一般需要在提交 PR 时，将关联的 ISSUE 标出，并说明该 PR 解决了什么问题。
而一些大的开源组织会有一些其他要求，比如 CNCF 的项目，在提交 PR 后 k8s-ci-robot[1] 会检测你是否签署了 Linux 基金会的贡献许可协议[2]（如果没有，就会要求你先签署一下该协议），同时还会做一些其他操作，比如根据内容打一些标签、做一些简单的测试，确保代码无冲突，并给你分配 reviewer（当然也可以使用 /assign 命令自己指定）。
﻿
Review在提交 PR 后，就会有人来对你提交的代码进行 review。当然，这个人并不会立即出现，因为大部分开源项目的维护者都不是全职的，并且如果该项目的维护者在国外，还需要考虑时差问题。
reviewer 会对你提交的内容进行一些评论，可能是需要更改的点，或者是需要增加一些相关的单元测试，这个过程将一直持续，直到这些内容达到合并的标准，当看到 /lgtm 时，恭喜你，你的代码通过 review 被合并了。
﻿
删除开发分支PR 被成功合并后，就可以对之前开发的分支进行清理了，因为在 review 中，会提交多个 commit，而合并一般会将这些 commit 压缩为一个 commit 然后合并到 master 分支，这就导致了 commit 信息的不一致，这也是为什么在前文要求不要使用 master 分支的原因，如果使用 master 分支，在提交几次 PR 后，就会多出很多很多的 commit...
﻿
删除分支
﻿
清理本地分支：
$ git branch -d xxx
这种方式就是通过分支管理，让 master 分支始终与上游仓库的 commit 信息一致，而从 master 分支 checkout 出开发分支，在开发分支内容合并入上游之后，只需同步 master 分支内容，然后重复上面的步骤就可以开始新的开发了。
总结﻿
以上就是这些年我参与开源项目的一些经验，是对网上一些文章的补充，其实不同开源组织的贡献方式不尽相同，在参与之前一定要先阅读贡献指南（Contributing Guidelines），这样会少走很多弯路。还有就是在 ISSUE 中的交流请尽量使用英语，哪怕你知道和你交流的是一名可以读懂汉语的人，这样做的原因是为了让其他不懂汉语的社区成员可以读懂你们交流，从而参与进来，而不是让人以为你们在“密谋”着什么。
﻿