傻子也能做开源

UP主: HDAlex_John · 时长: 18:55 · 🔗 B站原视频

发布: 2025-02-21 · 收录: 2025-02-23

标签: GitHub · 开源项目 · 程序员 · 简历加分 · 技术教程

目标：不用任何开发工具，网页端也能贡献开源

hi，这里是 ALEX。

今天我带各位尝试一下：不使用任何开发工具，不写一行代码，直接通过 GitHub 网站操作的方式，给开源项目做贡献，并且成为一个开源项目的贡献者。这样你就可以在简历上写：你是某某知名项目的贡献者（contributor）。

今天我们以一个小项目为例。这是一个不大不小的项目，刚好能够让我们得到比较及时的反馈。这个项目是一个基于 Vue 和 Next 的前端组件库，我之前做过相关视频。我在做视频时发现了它里面的一些 bug，所以就用这个 bug 带大家详细看一下：怎样给开源项目做贡献。

发现文档 bug：安装文档里 content 缺失

这个 bug 在开始文档的安装部分。第三步会设置一个配置文件，配置文件里有一段 content，但它的内容是缺失的。

这段内容其实在另一个安装文档里（Tiny CSS）已经给出来了，但这里漏掉了，也就是 content 的内容缺失。

我要做的很简单：把缺失的内容补上，添加到它缺失的位置就可以了。

在仓库里定位需要修改的文件

如果项目比较大，你在文档最下面通常能看到一个按钮叫 Edit this page on GitHub（在 GitHub 上编辑这个页面）。但我们这个项目比较小，没有提供跳转按钮，也不太好直接找到文档对应的路径。

没关系，我们直接在项目页面点 GitHub 图标的跳转链接，或者在网页最下面找到相关链接，跳转到 GitHub 仓库。

打开仓库后可以看到它 star 1700 多，issue 也不算很多。接下来要做的是：找到我们要修改的那段内容，在仓库里对应哪个文件。

我们看一下页面名字叫 installation。把这个名字复制下来，在仓库上方的 Go to file 搜索框里粘贴 installation，下面会出现匹配结果。这里第一个匹配是连贯的，而且位置也在 content，并且在 getting started 下面；我们当前页面的路由也在 getting started 下。

所以很明显，要修改的内容就在 installation.md 这个文件中。点击进入。

GitHub 网页端 Fork 并编辑文件

进入文件后，我们要改的地方在 content 这里。直接用浏览器搜索功能（Command + F）搜 content，就能定位到位置。

这时候你会发现只能选中，不能直接修改。想修改的话，在文件展示框右上角有一个笔的图标。鼠标悬停上去会提示：Fork this repository and edit the file，意思是先 fork 仓库，然后才能编辑文件。

fork 的操作，本质上就是在你自己的 GitHub 账号下，创建一个和原仓库一模一样的“克隆版”。你在这个克隆版里做修改，然后再把修改提交回原仓库。

点击笔图标后，会提示你需要 fork 这个仓库，点击 Fork this repository。稍等片刻，就会进入编辑页面。

编辑页面顶部会显示：原项目之前是组织名开头，现在 fork 之后前缀变成了你自己的 GitHub 账号名。这说明你现在编辑的文件不属于原始仓库，而是属于你 fork 出来的那份仓库。

补全 content，并用 Preview 检查渲染效果

在编辑页面里再次搜索 content，找到位置，把刚才缺失的内容写进去。这里一定要注意格式。

写完后如果不确定展示效果，点击 Preview。因为这是 Markdown 文档，编辑模式和展示效果差很多，用 Preview 看最终渲染结果最直观。

确认预览没问题之后，就可以提交了。

Commit：提交修改时的命名建议

点击右上角 Commit changes。commit 是提交，changes 是修改，也就是提交修改。

接下来需要给这次提交命名。这是比较重要的地方。我推荐各位给任何开源项目的修改写一个前缀，用来表示这次修改属于哪个方向。

比如这次是文档修改，就写 docs:（这里原文口误写成了 dogs），再加上具体内容描述。比如：

• 文档改动：docs: ...
• bug 修复：bug: ...
• 功能新增：feature: ...

这样维护者一看前缀就知道你改的是哪一块。

下面的 extended description 可以补充更详细的说明：这次具体改了什么。写完后点击 Propose changes，这样修改就提交到你 fork 的仓库里了。

提交后页面会展示 diff：左边是修改前，右边是修改后。

Pull Request：把改动提交回原仓库

现在改动还只在你自己的 fork 仓库里。我们最终目的是让原仓库合并你的修改，所以要提交 PR（Pull Request）。

点击 Create pull request，把你做的修改提供给原仓库作者。

进入 PR 页面后，需要认真写描述。通常 GitHub 右侧会提供贡献指南（contributing guide），告诉你需要遵守哪些规则。有些项目没有 CONTRIBUTING 文件就不会出现。

成熟项目很多会给 PR 模板；但这个项目没有模板，所以你只要清楚说明：你改了什么、解决了什么问题就行。

PR 描述：附截图、给文档链接做成 Markdown 超链接

我个人推荐在描述里加图片。

做法是：回到项目文档页面，找到有问题的地方，放大后截图，并在截图里用工具把问题框出来，最好用显眼的线标注。然后把图片放到 PR 描述里。

描述问题时可以写类似：

• Problem/Issue: The content attribute is empty, it will cause error during installation.
• 同时附上对应页面链接，方便作者定位。

如果你直接粘贴链接，预览里可能不够美观。可以用 Markdown 语法把链接变成文字链接：

• 用方括号包住要显示的文字：[文字]
• 后面紧跟圆括号放链接：(URL)

比如把 doc 这个词变成链接：[doc](链接)。

另外还可以把链接精确到第三步。点击页面里的“第三步”，地址栏会带一个 # 的锚点，把这个更精确的 URL 放到 PR 里，作者点开就能直接跳到你修改的具体位置。

确认描述没问题后，点击 Create pull request，PR 就提交成功了。

小改动也能被合并，不要有负担

有些朋友会觉得：我只是改了一两个字，或者只改了一行，这种看起来很“水”的修改作者会接纳吗？

不要有这种负担，也别太完美主义。

你可以在仓库的 Pull requests 里看看历史记录，把筛选条件里的 is:open 去掉，看已经被合并的 PR。比如这个项目里两天前作者刚合并了一个 PR，而且当天就处理了，说明作者响应很快。

点进 Files changed 可以看到，那位贡献者也只是改了一行，把单词拼写修正了（比如 complete 少了一个 L，补上而已），同样被合并了。

合并后这个人也会出现在 contributors 名单里。甚至有人只加一行、删一行，也在名单中。

所以给开源项目做贡献没有想象中那么难。

PR 被合并：出现在 contributors 名单里

过了一个晚上，我提的修改请求被通过了。

到 GitHub 页面上方，找到像“分支”一样的图标，确认它展示的是 Your pull requests。在这里筛选已关闭的 PR，找到最近一个，就能定位到昨天提交的 PR。

可以看到状态已经变成 Merged，之前是 Open。从时间上看，我的请求是 15 小时前提交的，作者在 11 小时前就合并了。

这意味着我们的修改已经进入原仓库。回到项目首页，右下角找到 Contributors，往下找就能看到我的名字出现在贡献者名单里。

这样我就可以在简历上说我是这个开源项目的贡献者了。也就是很轻松地“水”了一个 PR。

全程 0 代码：关键是让维护者检查起来更省事

整个贡献流程，我没有写任何一行代码，全程都在 GitHub 网页端完成。

需要注意的是：提交格式要方便代码检查者或项目维护者。以他们方便为前提，你的 PR 才更容易被接纳、更快被合并。

另外也要注意：这个项目对 PR 是否处理积极。我在提交前看了历史 PR，发现作者处理很迅速，所以我判断我这次也会很快被看到。

小技巧：通过维护者所在地时差判断“什么时候提 PR 更容易被看到”

如果你特别急，想知道你提交后会不会马上被作者看到，可以用一个小技巧：

先看之前处理 PR 的那位维护者是谁，点进他的个人账号信息（注意是个人账号，因为项目可能属于组织，组织可能有多个成员）。如果成员很多，就看历史 PR 主要是谁在处理。

进入这个人的主页后，如果他设置了所在地，GitHub 会显示位置。比如这个人在印度，那就查一下印度和我们时差是多少。印度一般比我们晚两个半小时。

这样你就能估计：你在什么时间提交 PR，更可能被对方及时看到，不至于一直干等。

结尾

以上就是本期视频的所有内容。希望你能关注或订阅我的频道，感谢观看，我们下期视频再见。