如何为开源软件做贡献？入门指南
欢迎在推特上关注我，我很乐意接受您对话题或改进方面的建议。/克里斯
简而言之，这篇文章旨在向对开源软件感兴趣的你展示如何入门，你需要输入哪些 Git 命令，以及一些你应该了解的概念。文章内容详尽，配有图片 :)
本文将涵盖以下内容：
- 规则和条例，让我们来谈谈您在开源软件开发和企业开发中应该做的事情。
- 入门指南将涵盖诸如如何fork代码库、创建本地分支、添加代码以及最终提交 PR（拉取请求）等内容。
- 处理变更请求时，贡献者会要求你更改一些内容，例如标题、提交记录，甚至如何将它们合并成一个提交，这些内容这里都有涵盖。
所以你很想知道如何为开源项目做贡献？很好，这种想法很棒。开源项目可以供所有人使用，所以你花点时间参与其中是一件非常好的事情，而且也很有趣，还能学到很多东西。
规章制度
参与开源项目确实有一些规则，这些规则的存在是有原因的。想象一下，一群开发者都想贡献代码，我们需要一种方法来确保他们的修改是以负责任的方式进行的。负责任可能意味着：
- 代码检查，即代码是否符合代码检查规则或其他遵循某种风格指南
- 测试方面，有一些更新的测试或新增的测试与您建议的更改相符。
- 提交要么被合并，要么被拆分成许多小的提交，每个提交只更改一项内容。为了使这种方式有效，每个提交都应该遵循某种命名标准，例如语义化提交。
入门
大多数项目不允许您直接将分支推送到主仓库，而是需要 fork 主仓库。fork 只是项目的副本，这意味着您不会直接影响您想要贡献代码的原始项目。这为您提供了在 fork 的仓库上自由实验的空间。那么，我们如何将这些更改合并到主仓库呢？为此，我们需要创建一个 PR，即拉取请求。然后，我们只需要让 PR 通过审核人员和持续集成 (CI) 系统的审核，搞定！您就可以称自己为贡献者了。让我们详细列出需要采取的步骤：
- fork该仓库
- 本地创建分支
- 在本地分支上添加代码，并可选择添加测试。
- 将更改提交到您的本地分支
- 推送代码并提交 PR
Fork 一个仓库
这一步很简单。只需点击“Fork”按钮，它就会在你的GitHub帐户上创建一个仓库副本。
创建分支
现在我们为本地代码创建一个分支。您可以一步完成创建分支和检出操作：
git checkout -b feature/name-of-my-feature
现在你可以根据需要修改代码了。
测试
最好在开始编写代码之前，先考虑如何测试你的修改。你需要添加集成测试还是单元测试？仔细查看你的项目，了解你如何构建和运行库/框架，尤其要注意如何运行相关的测试。开始添加代码后，你会看到是否有测试因此而失败。如果没有测试失败，那说明你运气不错，或者你可能需要自己添加一些测试。务必查看项目中其他测试的命名和代码风格。
承诺
我的建议是不要一次性提交太多更改。每次提交的更改要小而集中，并根据更改的内容进行清晰命名。例如：
feat: adding pagination to product list
或者
test: adding tests for pagination of product page
推送更改
一旦你完成了预期目标，就可以推送更改了。你可以通过输入以下命令来完成：
git push origin master
提升公关水平
在这里，您需要前往您在 GitHub 上的 fork 页面，然后选择该New pull request按钮。
选择后，您将进入如下所示的下一个页面：
在上方，我们需要在右侧选择我们的仓库以及已推送的分支。然后，我们需要点击绿色按钮（如果您尚未创建 PR，则按钮应显示“创建 PR”）Create new pull request。此时，您可以为 PR 命名，并勾选一些复选框，以便向维护者说明 PR 的内容。PR 创建完成后，按钮的文本将变为“创建 PR” View pull request。点击此按钮将跳转到相应的 PR。
现在，PR 已存在于您要修改的仓库中，其外观应如下所示：
请留意此页面上的评论，核心维护人员会告知您是否需要进行任何更改。此外，持续集成系统也可能会指出问题所在，并尽可能提供有用的错误信息：
处理变更请求
这个过程可能需要多次迭代才能成功。例如：
- 标题，您的公关稿标题需要更改
- 很难看出变化，你的提交内容不够小且不够集中，需要拆分，或者如果提交过多则需要合并。
- 测试失败，测试失败（你应该在本地测试时就发现这个问题，但世事难料 :) ）
更改公关稿标题
此次更改的原因可能是您的标题不符合特定标准。请务必查看仓库中提供的示例，了解正确的标题格式。
壁球承诺
此时，维护者表示，您的一些提交可以合并成一个提交。他们通常会告诉您哪些提交应该合并。合并意味着多个提交将被一个提交替换。那么我们该如何操作呢？此链接将告诉您所有步骤，但我们先来逐一了解。首先，我们来看第一个命令：
git rebase -i master
此时，您将看到以下内容：
此时我们可以看到所有的提交。所有提交都以 `<commit>` 开头，pick后跟提交 ID 和提交消息。对于要保留的提交，无需进行任何操作，即保留 ` pick<commit>` 关键字。在本例中，我们希望确保最新的提交被合并到最顶层的提交中。为此，我们按如下方式修改第二个提交：
上面我们按下了i进入插入模式的键，因为这是 VIM，是的，我知道如何退出 ;) 现在我们已经完成了想要的更改，让我们保存。按下Esc退出插入模式的键，然后输入 `\n`:和 `\n`，:wq这将保存更改并退出 VIM。
不，你以为退出 VIM 就这么简单吗？ ;) 现在你会看到一个页面，提示你修改提交信息。它会包含所有提交信息，如下所示：
字符 # 将被忽略，因此请调整其他文本，很可能您需要保留第一个提交信息，如下所示：
我们按下 Ctrl 键i进入插入模式，然后编辑文本，使其如下所示：
现在我们再尝试用 `.` 命令退出 VIM :wq。这次我们成功了，应该看起来像这样：
现在我们需要将代码推送到代码仓库。我们需要强制推送，所以我们输入：
git push -f
查看我们的公关稿，现在看起来是这样的：
只有一个提交结果，那就是成功。
重命名你的提交
好的，维护者这次似乎比较满意。不过，他们希望你把提交重命名为feature: adding install instructions。好的，我们可以这么做。为此，我们使用以下命令：
git commit --amend
这样我们就可以更新提交信息，更新后的信息应该如下所示：
您现在应该知道i如何进入插入模式并相应地更改消息了：
然后按 Esc 键退出插入模式，接着按:w. 现在，检查 git 日志，确认你的提交已相应更改：
好的，太好了，我们的提交名称已经更改了，至少在本地是这样。由于您在本地进行了更改，让我们将其推送到我们的仓库：
git pull // make sure you do this one first
git push
好的，此时你的仓库会在 Git 日志中创建一个合并条目，这意味着你实际上会有两条记录。那么，让我们再次开始这场混乱吧：
git rebase -i master
// change some commits to squash
git push -f
最后，我们还有这个：
概括
希望你的第一个 PR 现在已经合并成功了。恭喜你成为一名贡献者，你帮助了整个程序员社区。感觉工作量很大吗？其实，有很多开源软件维护者把这当成正式工作，而且你的工作成果很可能会被很多开发者使用，所以你应该庆幸，保证质量的流程相对简单。
文章来源：https://dev.to/itnext/how-you-can-contribute-to-oss-36id