前言
“开源”通常指开源模型,是一种去中心化的软件开发模型,它鼓励开放式协作,即“任何创新或生产系统都依赖于以目标为导向但松散协调的参与者进行交互来创建具有经济价值的产品(或服务),它们可以同时提供给贡献者和非贡献者”。由于开源具有包容性、众创性等诸多优点,使得众多开源软件及项目都获得了良好的可持续发展。参与开源项目也可以提升开发者的代码规范、架构设计、代码阅读等多项能力,那么如何参与开源项目贡献代码呢?目前出名的开源社区有 github、gitee 等,本文基于 Naive UI 来介绍如何在 github 上贡献代码(gitee 操作基本相同)。
Fork 代码
首先我们要明确一个概念,我们在 github 中进入一个开源项目后,实际是进入了别人/组织的仓库里的具体某个项目,这点从仓库名可以看出。例如:进入 Naive UI 后,仓库名为 TuSimple/naive-ui,即 TuSimple 组织的 naive-ui 项目。此时你如果直接 git clone
项目并修改项目内容,是无法使用 git push
推送的,因为没有仓库权限。而且就算有仓库权限,我也不建议对组织仓库的代码直接推送,这会使项目分支混乱,增加维护成本。所以,我们需要使用 Fork 操作将代码复制到自己仓库一份,点击仓库最右侧的“Fork”按钮即可。

Fork 时请顺便点击一下旁边的“star”按钮。
clone 代码并安装依赖
当点击完“Fork”按钮后,我们会发现项目的仓库名变为了我们自己的账号(如果没有自动跳转,则去自己仓库里找一下)。此时我们点击“Code”按钮,在下拉面板里选择适合自己的 Clone 方式,并复制 URL。

然后打开终端,进入自己想要存放项目代码的目录,执行:
git clone URL
git clone URL
其中 URL
为在 github 页面复制的 URL。等项目 clone 好后,终端进入项目,执行:
npm install
npm install
此命令为安装项目依赖,大家也可以选择其他工具安装,如果安装缓慢或失败,请设置国内镜像。
同步代码
由于我们代码来自我们自己仓库项目,而官方仓库代码发生改变时,我们自己仓库以及本地代码是不会同步更新的,所以我们需要手动来同步最新的代码。为了防止分支冲突,建议每次开发前都要同步官方仓库代码。首先设置项目的 upstream 仓库:
git remote add upstream https://github.com/TuSimple/naive-ui.git
git remote add upstream https://github.com/TuSimple/naive-ui.git
需要注意,此命令在 clone 项目后只需执行一次,命令中的 URL 为官方仓库的 URL。设置完 upstream 仓库后,我们需要拉取 upstream 仓库的最新代码,将本地分支切换到对应分支,然后合并最新代码到本地分支:
# 拉取 upstream 仓库 main 分支最新代码
git fetch upstream main
# 切换分支
git checkout main
# 合并 main 分支最新代码到本地当前分支
git merge upstream/main
# 拉取 upstream 仓库 main 分支最新代码
git fetch upstream main
# 切换分支
git checkout main
# 合并 main 分支最新代码到本地当前分支
git merge upstream/main
需要注意,此一系列操作需要随时做,保证我们本地代码永远是官方最新代码。
提交代码
通常开源项目都十分注重提交格式,不规范的提交格式会导致维护人员拒绝合并我们的代码(有的项目甚至配了提交检测工具,不规范的提交无法提交成功)。开源社区目前使用最多的是 Angular 规范 ,规范里写的很详细,这里就不过多赘述,列几个经常用到的:
# 新功能
git commit -am 'feat(button): add textColor prop'
# bug修复
git commit -am 'fix(button): fix bug for textColor prop'
# 文档修改
git commit -am 'docs(button): add demo for textColor prop'
# 新功能
git commit -am 'feat(button): add textColor prop'
# bug修复
git commit -am 'fix(button): fix bug for textColor prop'
# 文档修改
git commit -am 'docs(button): add demo for textColor prop'
提交 PR
PR 是 Pull requests 的简称,这里指将自己修改的内容提交到官方仓库的项目中。首先我们需要推送本地分支到 github 我们自己仓库中的项目:
git push --set-upstream origin branchName
git push --set-upstream origin branchName
其中 branchName
为我们要推送的分支名。推送成功后,我们需要到自己仓库的项目中,点击 Pull requests 标签,点击 New pull request 按钮。

点击 New pull request 按钮后我们跳到了官方仓库的项目中,不用担心,继续操作。分别选择目标分支和源分支,然后检查提交内容是否正确,最后点击 Create pull request 按钮。

然后我们来到 PR 信息页。PR 的标题会默认取 commit 信息,如果有多条 commit 信息时,建议起一个简洁、易懂并具有概括性的 PR 标题,当维护者选择合并 commit 信息时,会默认选择 PR 标题当做合并后的 commit 信息。PR 描述可以写自己为什么做出修改、修改的思路、关联 issues 等信息。做完以上步骤后,就可以点击 Create pull request 按钮提交。
大多数开源项目都有配置 PR 内容检测,当我们提交 PR 后会自动进行检测。有的项目会配置 Contributors 检测,即只有 Contributors 以上权限提交 PR 时进行检测。这就意味着如果你是第一次提交这个项目的 PR,检测机制不会被触发,当维护人员认为你的修改有必要时才会主动触发检测。我们提交 PR 后要经常注意 PR 的状态:查看提交是否被检测出问题,查看是否有维护者留言要求优化提交等。下图为 PR 检测时的样子,黄色为检测中,绿色为检测完毕且无问题,红色为检测完毕但有问题。

开发注意事项
单元测试
大多数开源项目都有自己的单元测试方案,并且会要求开发者添加当前 PR 的测试用例。单元测试既可以保证新功能的稳定可用,又可以降低项目代码修改、重构时的危险性,所以开始在开源社区贡献代码之前需要学习写单元测试。单元测试的学习非常简单,并且虽然现在不同框架都有自己单元测试方案,但实际大同小异,学会一种其他就都会写。Naive UI 使用的单元测试方案为 vue test utils 。
git 分支
大多数开源项目都要求开发者提交分支时保持分支的纯净,即:
- 保证自己提交分支上只有自己的 commit 信息;
- 保证自己提交分支上 commit 信息清晰易懂不多余。
想要保证这两点,需要开发者在本地开发时养成良好的 git 习惯:
- 不要在主分支(官方仓库的分支)上直接开发,每次开发都从主分支检出功能分支进行开发。
- 经常同步代码,如果代码有更新要使用
git rebase
检测是否有冲突,有就及时解决。 - 注意开源项目的分支规则,不要乱检出分支乱合分支。
- 如果发现自己分支有很多多余 commit 信息,也可以用
git rebase
合并。
开发操作流图示
为了方便大家理解整个流程的操作,这里放一个流程图。
