我们如何处理 Elastic Pull Request

By
Elastic Engineering

Elastic 通过协作来完成各项工作。

我们的工程师 24 小时不停地工作（确实如此，因为我们是一家 分布式公司）来开发新产品和功能。这是一项巨大的工作，需要仔细关注细节。但是不管我们有多小心，我们都无法做到完美，对于任何像我们这样复杂的开源项目，我们仍然需要社区的帮助来使它变得更好。

在使用 Fix-It Friday 解决小但重要的问题中，我们讨论了社区的贡献如何推动我们不断成功开发产品。作为一个开源项目的一大好处是，我们有一个庞大的开发者社区，他们会寻找漏洞，并急切地等找到堵住漏洞的机会。

如果您是社区的新成员，并且是第一次提交您的 Pull Request (PR)，或者对这个过程的工作方式有疑问，那么您来对了地方！在这篇文章中，我们将概述 pull request 是如何帮助 Elastic 运作的，我们收到 pull request 时如何进行处理，以及如何避免可能妨碍您的建议得到采纳的常见错误。

那么，我如何提交 Pull Request？

提交 PR 之前，您需要在 GITHUB 存储库中创建一个分叉，并对代码进行更改。这通常是在您自己的 GitHub 帐户下完成的，它会为您创建一个源存储库的副本。我们所有的项目都存在它们自己的 GitHub 存储库中。GitHub上的 Elastic 组织页面上提供了我们存储库的完整列表。 

一旦创建了存储库的分支并更改了代码，系统会询问您是否要创建 PR，并将建议的更改推送到产品存储库的主分支。例如，Elasticsearch 存储库，如下所示。为了简单起见，我们将在这篇文章中展示 Elasticsearch 存储库中的例子。

当您点击“New pull request”（新建 pull request）时，您会首先看到我们的 pull request 模板。

这个模板将为您提供指导，帮助您的 PR 通过第一次审查，所以一定要通读，因为每个产品都有自己的标准和文档。模板会给您指导，帮助您的 PR 通过第一次审查。

提交时确保避免这些常见错误：

  • 提交重复项 - 首先，根据您的代码要修复的错误，搜索有没有打开的 PR 已经在解决这个问题。副本通常被拒绝。
  • 不包括测试 - 包含代码更改的 PR 应包括说明新代码行为的测试。理想情况下，这个测试应该重现 PR 正在修复的问题，这样测试在没有代码的情况下会失败，而在应用代码时通过。
  • 仅主分支 - 确保任何更改代码的 PR 均针对相关目录中的主分支提出。

完成模板中列出的所有要求后，单击“创建 Pull Request”。现在一切准备就绪了。

分门别类和添加标签

我们的第一步是确保 PR 符合一个好请求的标准（如上所述），如果符合，就给 PR 贴上标签，这样会有合适的审核者来查看，以便进一步评估。标签可能包括 >bug、>功能等等。一旦 Pull Request 有了标签，它就会被分配给适当的子团队来处理。在这之后，处理请求是负责该领域的团队进行。

开始进程

一旦 PR 被贴上标签，它就会被我们的一个开发者领取。我们会尽快回复请求者，不过我们请您在提交 PR 时有耐心，因为由于请求的级别和深度各不相同，正确处理请求可能需要一些时间。 

提交文件变更

注意：我们还收到许多修改或请求修改我们文档的 PR。这个过程比代码更改简单得多 — 只需要在 Elastic 文档页面上点击“编辑”，进行更改，然后提交请求。不需要分叉项目，也不需要测试。我们用“>doc”标记这些 PR，并尽快处理。

通常，我们有更多的工作要做

PR 通常需要在准备合并之前进行调整。此时，PR 变成了一个协作空间，社区成员在这里进行讨论，提出改变，并做出更多改进。

在审查过程中，我们对会 PR 进行测试，测试结果可以在 GitHub 上看到。有时，即使提交的测试有效，当应用 PR 中的更改时，测试也可能会失败。不过，这并不是最后的结果。我们将帮助贡献者修复贡献的代码，以便所有测试都通过。

代码风格以及代码和命名约定，也是我们在这个阶段关注的问题。提交 Pull Request 的用户应该注意：他们的代码会至少经过一轮审查。代码从来都不是完美的（甚至我们的代码都不完美！）并在提交时准备用于合并 — 因此，在此过程中可能需要您的合作。

我的 PR 需要多长时间才能被纳入？

每个 PR 的处理时间有所不同。一行简单的代码可能会被快速处理，但是复杂的代码更改会经过多轮审查。如果您觉得您的 PR 已经提交了很长时间但是没有任何动静，可以开一张支持请求来提醒我们此 PR 仍处于活跃状态。

纳入代码

当一切准备就绪时，评审者会在批准操作中添加一条评论 — 可能是 LGTM（“我觉得不错”）评论，或者类似的内容。PR 被接受后，Elastic 开发人员会将 pull request 合并到主分支中，然后根据需要将更改返回到开发分支。

简而言之，这就是它的工作原理。当然，Pull Request 各不相同。这个过程可能非常简单，也可能很困难。您深入了解这一过程的唯一方法是卷起袖子亲自操作。

准备好提交您的第一份 PR 报告了吗？浏览 GitHub上提供的 Elastic 存储库，熟悉这些指南，并尝试一下。如果您对这个过程有任何进一步的疑问，那么就去我们的讨论论坛，并创建一个主题，我们会很乐意提供帮助。