如何为开源项目贡献力量

以下内容将略带主观意见，旨在指导您踏上开源之旅。作为先决条件，您应该熟悉基本的命令行和 Git。如果您了解这些概念并希望直接进入逐步操作指南，查看文章的这一部分。

实际上，没有一种通用的方式来为开源项目贡献力量，参与其中通常不仅仅是编写代码。然而，在本文中，我们将重点关注向 GitHub 上其他人的项目提交拉取请求 (PR) 的细节。

让我们设定一下场景...

你在 Github 上发现了某个人的项目，你非常喜欢它！你甚至可能会决定在自己的项目中使用它。但你注意到了一些小细节... 可能是一个错误。可能是一项对现有功能的增强。也许你浏览了代码，发现了一种更清晰、更优化的编写方式，即使只是代码中额外的缩进。

以下是一些关于从这里开始的初步建议和说明。

查找文档中的 CONTRIBUTING.md 文档或贡献指南

许多开源项目都明白其他人可能希望贡献力量。如果他们发现自己反复回答同一个问题，这份文档旨在让每个人更容易达成一致。

在贡献指南中，你可能会发现一些内容

• 风格指南
• 提交 PR 的先决条件
• 如何将你的更改添加到他们的文档中
• 贡献的核对清单
• 解释项目的架构和设置

这份文档可以很简单，只包含几个笔记，也可以非常详细，需要花一些时间才能看完（例如 Atom 的贡献指南）。

对于大型项目来说，在开始之前就明确贡献指南很有必要，因为 PR 和 issue 会堆积起来，让维护者很头疼，他们需要从可能超出项目范围的贡献中进行筛选。如果存在贡献指南，请务必花一些时间阅读它，因为你的 PR 也需要维护者花时间。

查看现有的 issue 和 PR

在添加新 issue 或提交 PR 之前，最好检查一下现有的内容。你可能会发现有人已经问过同样的问题，或者提交过类似的内容。你可以使用项目的搜索框进行搜索——我通常会搜索公开的和已关闭的 issue，因为了解是否有人已经提出过我的问题，以及维护者是否决定采取其他方向很重要。再次强调，这样做是为了节省你和维护者的时间。

提交 issue

提交 issue 是 PR 提交过程的核心部分。它们提供了一个机会，让你可以阐述情况，建立相关背景，并提供一个可以附加到 PR 本身的讨论论坛。

在提交 issue 时，我喜欢写下我的问题，然后重新阅读它，就像我是接收方一样。人是会犯错的——即使你说的技术上是正确的，但如果你的语气不友好，你也不太可能得到别人的支持。想想这个：你可能会要求别人在业余时间做很多工作。如果有人要求你星期六去工作，你会更容易答应吗？还是说他们会带着轻蔑的语气要求你？你懂我的意思吧。

在提交 issue 时，请确保你提供他们完成工作所需的所有细节。你可以注意到一些事情

• 如果是错误，那么你在什么环境中看到了问题？是开发环境还是生产环境？或者其他地方？
• 如果是功能请求，那么请解释一下问题。有时以用户故事的形式从最终用户的角度来阐述这个问题会很有帮助，既可以帮助你理解情况，又可以将其抽象化，避免任何个人感情的影响。
• 如果是普通问题，那么请在开头说明，这样维护者就可以避免浪费时间试图弄清楚你是在问错误还是功能。
• 如果你想提交一个 PR 来改进这个问题，请提到你想这样做，然后请求许可继续进行（因为有时维护者可能有其他计划，你可能不知道）。

开始工作前要考虑的事情

你可能迫不及待地想开始编写你的 PR。但首先，在你开始深入之前，还有几个惯例需要检查。

先询问

我非常赞成在编写 PR 之前，先在 issue 中询问是否合理。我并不将其视为一项严格的规则，但有时如果我们能事先澄清彼此的想法，就能节省很多时间，避免走错方向。这也让其他人知道不要实现相同的功能（假设他们也浏览了公开的和已关闭的 PR）。

使用标签

如果你提交了 issue，并且大家都同意编写 PR 是一个好主意，那么你（或仓库的拥有者）最好添加 in progress 标签。你可以搜索标签，这样每个人都清楚地知道你正在处理它。

分块工作！

作为一名维护者，当有人投入大量工作并提交了一个巨大的 PR，里面包含了 10 种不同的东西，我会感到很沮丧。要审查它真的很难，而且不可避免地，他们做了六件你想要的事，而四件你不想做。不仅如此，它通常还分布在多个文件中，这很难理清。我确实关闭过一些高质量代码的 PR，只是因为审查和管理它需要花很长时间。（不过，如果他们想重新提交工作作为单独的 PR，我会说明这个问题。）

在我看来，如果你将内容分成多个较小的 PR，那么你的 PR 被合并的概率将提高 1000%，你所花费的时间也会得到认可。我喜欢人们针对每个主题提交一个 PR。而且，虽然不是必需的，但如果每个提交之间间隔一段时间，也能减轻认知负荷。

提交你的 PR

这些是我个人提交 PR 的步骤。当然，你也可以用其他方法完成它，但我发现以下方法在我的经验中非常有效。此外，命令中以 大写 形式写出的任何内容都是你需要根据自己的情况更改的信息。

首先，前往项目仓库，并将其复制到你的个人 GitHub 账户。 在本地克隆它并更改目录（`cd`）到它所在的目录。 （我使用 HTTPS，但 SSH 也是完全可以的。）

git clone https://github.com/YOUR-USERNAME/YOUR-FORKED-REPO.git
cd into/cloned/fork-repo

接下来，将一个远程上游分支添加到原始分支。 这意味着它将与原始分支共享连接，以便你可以保持同步并在发生更新时拉取项目的所有更新。

git remote add upstream https://github.com/ORIGINAL-DEV-USERNAME/REPO-YOU-FORKED-FROM.git
git fetch upstream

现在你可以创建一个新的分支，并为它命名，该名称与 PR 主题相关。 请注意，维护人员可能会有特定的命名约定，这些约定在仓库中有所记录。

git checkout -b GOOD-FORKIN-NAME

开始进行你的更改。 确保在过程中 编写良好的提交信息

git add -A
git commit -m “ADDING IN A TACO DISPENSER”
git push origin GOOD-FORKIN-NAME

GitHub 将看到新的分支并提示你创建 PR，这是一个很贴心、有帮助的操作。 你点击按钮并填写详细信息：它解决了哪个问题？你可以通过它们的编号来引用它们，GitHub 会自动将它们关联起来。

在 PR 中

PR” 上引用的问题 />

在问题中

在 PR 中需要注意哪些事情？ 这些细节可以帮助维护人员了解上下文。 它们可以是你所做的所有更改，也可以是更大的策略或上下文。

现在你已经开始你的旅程了！🎉

你可能会发现你需要将你的分支与远程分支保持同步，并将他们的更改拉取到你的分支中。 要做到这一点，你需要运行以下命令：

git pull upstream master

感谢 Cristina Solana 提供的 Gist，我已经将它用作参考多年了。

永远记住：维护人员通常都很忙，牺牲夜晚和周末来保持开源项目的活跃和更新。 对他们的时间和语气保持尊重，可以让你在贡献时获得成功。

---

开源可以带来极大的回报！知道其他人正在受益并直接使用你所贡献的东西，可以成为回馈社区和学习的好方法。