您的第一个开源拉取请求：演练

“你应该为开源做出贡献。”——互联网。

也许你见过这个建议。它要么来自那些相信自由软件的人，要么是为了求职而提出的建议。很多人（包括我的一些学员）都说 GitHub 很吓人。那里的项目比他们之前参与过的任何团队项目都要庞大。参与这些项目的人，就像一群认真的人一样。

这既是事实，也是谬误。真的没什么好担心的。我们来聊聊具体细节。我将以我昨天对 Jekyll 做的一点小 贡献为例。有很多资源可以帮助你找到首次遇到的问题，但这些指南忽略了一些步骤。

发现问题

相比于快速上手一个你从未听说过的项目，在日常使用的软件中查找（或记住）错误会更容易。就拿 Jekyll 的 minima 主题来说吧。很久以前，我想让我的网站看起来与众不同，但我没有时间从头开始写一个主题——所以我一直在琢磨这个主题。

我发现这个 bug 是这样的。我打开开发者工具（F12），将 view-size 设置为iPhone 5/SE（以现在的标准来看，这个尺寸相对较小），用来测试我网站的一个页面。有些开发者不会考虑这种尺寸的设备（但他们应该考虑）。我发现响应式页脚显示不正确。页脚不是堆叠的两列，而是两列，其中一列是空的。

起初，我以为是我的一些黑客行为导致了这个问题。于是我去了jekyll/minima仓库，仔细检查了上线的演示页面。我发现了同样的问题（注：这个问题已经在主分支上修复了）。问题出在一个错误的类上——.one-half它没有响应式地运行。（我通过一些 Dev Tools 的调整发现了这个问题）。

它需要一个媒体查询。媒体查询是指我们的网站根据设备设置（例如分辨率）更改样式的方式。您无需了解您正在修复的项目背后的整个技术栈。例如，我很少使用 Sass，但我知道它的 CSS 变量系统。我四处寻找一个已经在使用的断点变量，它可以补充所有尺寸的页脚列。我选择了$on-large— ，最终问题得到了解决。

分叉

查看贡献指南。这比我能给你的任何建议都重要。对于 jekyll/minima 来说，指南非常简单：“欢迎提交 Bug 报告和拉取请求”，以及指向行为准则的链接。它还会告诉你应该将更改发送到哪个分支。

jekyll/minima 是基于 jekyll/minima 开发的，master但通常会有一个临时分支供您 fork。请在浏览器中访问 GitHub 仓库，点击Fork按钮，然后将分支克隆到您的电脑上。社区建议学习使用命令行工具进行 Git 交互，但GitHub Desktop客户端也很好用。如果有测试套件，请在更改任何内容之前运行测试，以确保您的环境稳定。

创建拉取请求

进行修改并撰写良好的提交信息。我的提交信息是“修复较小视图尺寸下的页脚堆叠问题”。将修改推送到你的 fork 分支。虽然可以通过命令行创建拉取请求，但我访问的是 fork 分支的仓库，然后点击文件列表右上角的“拉取请求”按钮。

我一直认为，编写拉取请求与编写代码同等重要。如果你的团队成员无法从高层次理解提议的变更，那么他们将无法成功地对其进行评审。这意味着你的拉取请求可能会被拒绝（或在不该被接受的情况下被接受）。对于错误，我会描述错误，并在合适的情况下附上图片，然后解释修复错误需要进行哪些更改。如果有重要的、技术性较强的实现细节，我会把它们放在最后。

最后再看一下贡献指南（CONTRIBUTING.md如果找不到可以看看），然后就可以提交了。检查一下拉取请求的阅读、评论和合并频率。确保你了解回复可能需要多长时间，这样才能满足你的期望。（我的小修复过程不到一天就完成了）。

处理批评

您可能想勾选“允许维护人员编辑”，以便更轻松地进行细微的样式更改。一位 GitHub 用户感谢了我的修改，并发现我正在处理的区域还有更多修复。我查看了一下，但无法找到一个干净的解决方案来解决这些额外的修复。对于这些额外的修复，需要进行一些小规模的架构调整，而我没有时间进一步研究代码库。基本上，您可以拒绝——我们都是在这里自愿贡献时间的。

将你自己与你的拉取请求区分开来。你的代码并不代表你。例如，你可能不熟悉项目其他地方使用的设计模式。最糟糕的情况就是有人建议你再试一次。你会惊讶地发现，开源社区的人们是多么乐于助人、多么热情好客。

我们希望你成功！如果你对拉取请求感到焦虑，可以在我的一个小项目中提交一行代码的修改。我会微笑着迎接你😊。

与 150 多名订阅我的关于编程和个人成长的新闻通讯的人一起！

我发布有关科技的推文@healeycodes。