如何为开源软件做出贡献

如果您和我一样，您想为开源软件做出贡献，但却不敢将您的第一个拉取请求发送到另一个团队的存储库。

在本文中，我将分享我首次参与大型开源项目的经历。我希望这能帮助大家消除使用其他团队代码的恐惧感，并让你体验到在一个更大的社区中工作是多么酷炫。

在本文中，我将专门讨论微软 .NET 文档项目的拉取请求 (pull request) 。我提供的工作流程、工具和示例将针对该项目及其维护团队，但其广泛的概念应该适用于您遇到的许多项目。

寻找可以贡献的项目

不用说，为了做出贡献，您需要选择一个您想要贡献的项目。

上周末我得知自己被.NET基金会接纳了。对于我这个微软的终身粉丝（以及自2001年以来一直是.NET的粉丝）来说，这可是个大喜讯，这让我渴望为任何与.NET相关的领域做出更多贡献。

碰巧的是，我在 Twitter 上发现了一个引起我兴趣的帖子：

我决定听取他们的建议，查阅一下.NET文档项目。毕竟，撰写技术文章只是我的强项。

选择一个好的第一期

一旦选择了存储库，您就需要找到一种开始的方法。

有时你会对某些需要改变的事情有强烈的意见。有时你可能只是想帮助团队解决一些悬而未决的问题。

如果您只是尝试贡献一些特定内容，可以跳过本节的大部分内容，直接开始实际操作代码。也就是说，如果您贡献的内容并非修复拼写错误或使示例代码能够正确编译，那么您确实应该在他们的代码库中为即将完成的工作创建一个问题。这可以确保您的工作被需要，并且代码库所有者可以在您投入时间之前对其实现进行评论。

如果您不确定要处理什么，请前往仓库的“问题”选项卡，查看可用的标签。您需要查看当前处于打开状态且带有“优质首个问题”、“待处理”或类似标签的问题。

微软的文档团队已经彻底审查并评论了他们积压的所有内容，我可以轻松地找到可用的问题。

现在，您需要找到一个问题，它看起来既是您感兴趣的问题，也是存储库新手可能容易解决的问题。

就我而言，我选择了对 C# 和 VB .NET 中 INotifyPropertyChanged 示例的改进。原有的代码还不错，但 .NET 会随着时间推移而发展，并且随着它的发展，会出现更好的实现方式。这是一个在我擅长的领域分享最佳实践的机会，所以我抓住了这个机会。

了解问题

每当你遇到一个现有问题时，都需要仔细彻底地阅读其描述以及历史记录中的每条评论。代码库所有者和问题创建者可能已经在某种程度上表达了意见，出于对他们代码的尊重，你应该理解这个问题以及他们在解决问题时的意图和顾虑。

就我的情况而言，这对于 .NET 文档团队来说非常典型，团队已经彻底审查并讨论了这个问题，并且我得到了一些非常有用的评论可以依赖。

我还发表了一条评论，表明我打算处理这个问题以及我打算做出的修改。部分原因是想看看团队是否会把这个问题重新分配给我，或者要求我处理其他问题，但我没有收到任何回复。

分叉并克隆存储库

尽管您可以在本地克隆存储库而无需对其进行分叉，但除非您先分叉存储库，否则您将无法发出拉取请求。

值得庆幸的是，fork 非常简单。只需点击 GitHub 上的“Fork”按钮，它就会引导你创建该仓库的副本。

一旦存储库被分叉，请按照 GitHub 的提示将分叉的存储库克隆到您的机器上。

我是GitKraken作为 Git 客户端的忠实粉丝，因此我复制了 URL 并使用该 URL 从 GitKraken 克隆，但命令行或您选择的其他应用程序也同样适合您。

了解团队的工作流程

下一步将根据您参与的项目和团队而有所不同。首先，您需要确定应该基于哪个分支进行更改。接下来，您需要了解团队是否针对其分支选择了专门的 Git 工作流程或命名规范。

值得庆幸的是，您不需要在大多数存储库中猜测这些内容，因为社区已经标准化了创建contributing.md或readme.md文件，它将引导您如何开始使用存储库，包括分支结构和 git 工作流程。

如果没有相关文档，请小心，因为团队可能不欢迎新的贡献者。

就我而言，.NET 团队提供了一份非常有用的贡献指南，但你可能得不到。你可能需要通过查看过去的提交来推断模式，甚至亲自联系仓库所有者。

在开始使用编辑器之前，我建议你先根据合适的起始分支（参见前面的讨论）在 Git 中创建一个分支。务必检查之前的分支以及contributing.md和/或readme.md文件的命名规范。

分支名称并不是世界末日，因为您稍后会向另一个存储库提交拉取请求，但它可以帮助您感觉自己属于使用一致的名称。

确定自己的方向

好的，现在您已经有了本地代码，您需要使用您所使用的语言所需的任何编辑器来打开项目。

就我而言，该编辑器应该是 Visual Studio，但是我在存储库的根目录中找不到.sln文件，因此我认为该项目应该是 Visual Studio Code 工作区。

我很高兴在 Visual Studio Code 中打开文件夹，然后系统提示我该工作区与一组推荐的扩展程序关联，并询问我是否要安装它们。我当然接受了，Visual Studio Code 也进行了自我配置，让我能够以与维护人员类似的方式查看代码。

您不太可能与像 Microsoft 文档团队这样出色的团队合作（如果您这样做，我相信他们会很乐意听到他们可以改进的地方）。

即使有了这些实用的指导，你仍然需要熟悉项目结构。虽然这些contributing.md指导可能有助于理解某些文件夹，但我通常项目的第一步就是打开文件夹和子文件夹，直到开始看到重复的组织模式。

一旦我开始识别模式，我就会开始寻找与我将要更改的代码相关的文件。

就我而言，微软通过在 GitHub 上的问题中记录它们，再次使事情变得异常简单。

因此，针对这个问题，我查找how-to-implement-property-change-notifications.md并查看了 markdown 文件中包含要更新的代码示例的部分。

我的发现令人惊讶：

它没有引用包含示例的页面，而是引用了团队维护的另一个 git 存储库中的示例：Samples 存储库。

这有点困难，因为我必须分叉并克隆该存储库，然后在该项目的结构中找到我正在寻找的文件。

对我来说，第二个存储库是整个体验中最大的缺点。嵌套的存储库设计让我更难定位，也更难对我所做的事情有信心，因为我无法轻易地看到包含我修改的 Markdown 文件。

我相信微软这样设计是为了让想要下载示例并在本地使用它们的开发人员更轻松，因此团队为了更大社区的利益牺牲了自己的生产力。

进行并测试您的更改

一旦您知道自己处于正确的位置，您就需要进行必要的修复或增强，进行测试，然后提交相关文件。

构建、运行测试、运行 linters（如果适用）以及以其他方式验证您的代码非常重要，并且是成为更大社区中负责任的软件工程师的重要组成部分。

值得庆幸的是，大多数大型项目都在拉取请求流程中内置了自动检查功能，以确保您的代码符合团队标准，但在创建拉取请求之前确保您的代码在本地运行良好可以避免一些麻烦。

代码提交后，请务必将其推送到你fork 的版本库。此步骤对于创建拉取请求至关重要。

创建你的拉取请求

现在您已经推送了更改，您可以返回到分叉的存储库并通过单击相应的提示来创建拉取请求。

左侧的分支和仓库表示您要合并到哪个仓库和分支。该仓库应该是项目的主仓库，而分支通常与您分支出来的仓库相同。右侧的分支和仓库表示您刚才使用的分叉仓库及其分支。

现在您已经设置了目标，请遵循团队的命名惯例来命名您的请求。就我而言，我会在括号中填写提交的描述性标题以及问题编号。

团队还使用模板自动填充拉取请求正文的内容，我使用 markdown 语法写下了我所做更改的详细列表。

请注意，最后一个“like”是说Fixed dotnet/docs#10675。

这是一个神奇的字符串，GitHub 会解析它来将我的提交与docs存储库中的正确问题（#10675）关联起来（回想一下，我正在对存储库进行更改samples）。

如果您对于正在使用的存储库的拉取请求中应包含哪些内容有任何疑问，请花一些时间查看过去的拉取请求、其内容以及对这些请求的任何评论。

准备好后，单击Create pull request。

接下来会发生什么？

恭喜，你为开源软件社区做出了一点贡献。然而，旅程尚未结束。

您的代码可能需要通过自动化检查（通常是构建，也可能是代码分析）才能进行审核。此外，项目维护人员需要审核您的更改，并选择是否接受这些更改并将其合并到源码仓库中。

就我而言，第二天早上审查了这些更改，我收到了一条友好的消息和通知，说我的拉取请求已被接受并且问题已关闭。

我所做的更改在当天就生效了，这意味着从我分叉他们的存储库、进行更改，到这些更改被审核、批准并部署到生产环境，中间还不到 24 小时。

结束语

正如我所说，我一直是微软的忠实粉丝。然而，当我收到这条消息时，我并没有想到自己会感到如此自豪。我的改变只是个小改变，而且是团队帮我轻松完成的，但能为我所关心的事情做出一点小小的贡献，我感到无比自豪。

我强烈建议你尝试为开源软件做贡献。找一个你感兴趣的项目，找到你感兴趣的内容。如果找不到，可以像我一样尝试使用微软的文档，或者在 Twitter 上发帖说你正在寻找一种小小的方式来帮助某个项目。

从小事做起，看看事情进展如何，然后逐步达到你喜欢的程度。

社区很棒，如果你尊重人们的流程、代码和工作流程，他们通常会非常乐于助人并感谢你的帮助——即使你的代码或评论并不完美。

开源软件开发很棒。它只需要你的一点帮助。

如何为开源软件做出贡献一文首先出现在Kill All Defects上。