补丁编写指南

以下是一些来自 Matz 的关于如何让您的补丁被考虑的建议。

这些指南采纳自 Matz 在 Ruby-Core 邮件列表上的一篇 帖子

• 每个补丁实现一项修改

  这是大多数被推迟补丁的最大问题。当您提交一个一次性修复多个 bug（并添加功能）的补丁时，我们必须在应用它之前将其分开。对于我们这些忙碌的开发者来说，这是一项相当艰巨的任务，因此这类补丁往往会被推迟。请不要发送大型补丁。

• 提供描述

  有时一个简单的补丁不足以充分描述它所修复的问题。一个更好的描述（它修复的问题、先决条件、平台等）将有助于补丁被更早地合并。

• 基于最新修订版进行 diff

  您的问题可能已经在最新修订版中得到修复。或者代码可能已经完全不同了。提交补丁之前，请尝试从 Subversion 仓库获取最新版本（最新开发版本的 trunk 分支，2.6 版本的 ruby_2_6 分支）。

• 使用 diff -u

  我们偏好 diff -u 风格的统一 diff 补丁，而不是 diff -c 或任何其他风格的补丁。它们更容易审查。不要发送修改过的文件，我们不想自己制作 diff。

• 提供测试用例（可选）

  提供测试用例的补丁（最好是 test/*/test_*.rb 的补丁）将有助于我们理解补丁和您的意图。

未来我们可能会转向 Git 风格的 push/pull 工作流。但在此之前，遵循以上指南将有助于您避免沮丧。