为 Ruby on Rails 做贡献

1 报告问题

Ruby on Rails 使用 GitHub 问题跟踪 跟踪问题（主要是错误和新代码的贡献）。如果您在 Ruby on Rails 中发现了错误，请从这里开始。您需要创建一个（免费的）GitHub 帐户才能提交问题、评论问题或创建拉取请求。

1.1 创建错误报告

如果您在 Ruby on Rails 中发现了一个不是安全风险的问题，请在 GitHub 上搜索 问题，以防它已被报告。如果您在 GitHub 上找不到任何解决您发现的问题的开放问题，您的下一步将是 打开一个新问题。（有关报告安全问题的说明，请参阅下一节。）

我们为您提供了一个问题模板，因此在创建问题时，您将包含所有必要的信息，以确定框架中是否存在错误。每个问题都需要包含标题和问题的清晰描述。确保包含尽可能多的相关信息，包括代码样本或失败的测试来演示预期行为，以及您的系统配置。您的目标应该是让自己 - 和其他人 - 能够轻松地重现错误并找出解决方法。

打开问题后，它可能不会立即看到活动，除非它是一个“代码红色，任务关键，世界末日”类型的错误。这并不意味着我们不在乎您的错误，只是有许多问题和拉取请求需要处理。遇到相同问题的人可以找到您的问题，并确认错误，并可能与您一起修复它。如果您知道如何修复错误，请继续打开一个拉取请求。

1.2 创建可执行的测试用例

能够重现您的问题将有助于人们确认、调查并最终解决您的问题。您可以通过提供一个可执行的测试用例来做到这一点。为了使此过程更轻松，我们为您准备了一些错误报告模板，供您用作起点

• Active Record（模型、数据库）问题的模板：链接
• 测试 Active Record（迁移）问题的模板：链接
• Action Pack（控制器、路由）问题的模板：链接
• Action View（视图、助手）问题的模板：链接
• Active Job 问题的模板：链接
• Active Storage 问题的模板：链接
• Action Mailer 问题的模板：链接
• Action Mailbox 问题的模板：链接
• 其他问题的通用模板：链接

这些模板包含设置测试用例的样板代码。将相应模板的内容复制到 .rb 文件中，并进行必要的更改以演示问题。您可以通过在终端中运行 ruby the_file.rb 来执行它。如果一切顺利，您应该看到您的测试用例失败。

然后，您可以将可执行的测试用例作为 gist 共享，或将内容粘贴到问题描述中。

1.3 安全问题的特殊处理

1.4 功能请求呢？

请不要将“功能请求”项目放入 GitHub Issues 中。如果您想在 Ruby on Rails 中添加新功能，您需要自己编写代码 - 或者说服其他人与您合作编写代码。在本指南的后面，您将找到关于为 Ruby on Rails 提交补丁的详细说明。如果您在 GitHub Issues 中输入了没有代码的愿望清单条目，您可以在它被审核后立即将其标记为“无效”。

有时，“错误”和“功能”之间的界限很难区分。通常，功能是任何添加新行为的东西，而错误是任何导致错误行为的东西。有时，核心团队需要做出判断。也就是说，这种区分通常决定您的更改将与哪个补丁一起发布；我们喜欢功能提交！它们只是不会被移植到维护分支。

如果您想在进行修补工作之前获得有关功能想法的反馈，请在 rails-core 讨论板 上开始讨论。您可能没有得到任何回复，这意味着每个人都无动于衷。您可能会找到对构建该功能也感兴趣的人。您可能会得到一个“这将不被接受”。但它是讨论新想法的适当场所。GitHub Issues 不是进行新功能有时需要进行的漫长而复杂的讨论的特别好的场所。

2 帮助解决现有问题

除了报告问题之外，您还可以通过提供有关问题的反馈来帮助核心团队解决现有问题。如果您不熟悉 Rails 核心开发，提供反馈将有助于您熟悉代码库和流程。

如果您查看 GitHub Issues 中的 问题列表，您会发现许多问题需要关注。您能对这些问题做些什么？实际上，您可以做很多事情。

2.1 验证错误报告

首先，验证错误报告很有帮助。您可以在计算机上重现报告的问题吗？如果是，您可以向问题添加一条评论，说明您也看到了相同的问题。

如果问题非常含糊，您能帮助缩小范围使其更具体吗？也许您可以提供其他信息来重现错误，或者您可以消除演示问题所不需要的不必要步骤。

如果您发现没有测试的错误报告，那么贡献一个失败的测试非常有用。这也是探索源代码的好方法：查看现有的测试文件将教会您如何编写更多测试。新的测试最好以补丁的形式贡献，如后面的 贡献到 Rails 代码 部分所述。

您能做任何事情来使错误报告更简洁或更容易重现，都有助于试图编写代码来修复这些错误的人 - 无论您最终是否自己编写代码。

2.2 测试补丁

您还可以通过检查通过 GitHub 提交到 Ruby on Rails 的拉取请求来提供帮助。为了应用某人的更改，首先创建一个专用分支

$ git checkout -b testing_branch

然后，您可以使用他们的远程分支来更新您的代码库。例如，假设 GitHub 用户 JohnSmith 已分叉并推送到位于 https://github.com/JohnSmith/rails 的主题分支“orange”。

$ git remote add JohnSmith https://github.com/JohnSmith/rails.git
$ git pull JohnSmith orange

除了将他们的远程添加到您的检出之外，还可以使用 GitHub CLI 工具 来检出他们的拉取请求。

应用完他们的分支后，对其进行测试！以下是一些需要考虑的事项

• 更改是否真的有效？
• 您对测试满意吗？您能理解他们在测试什么吗？是否缺少任何测试？
• 它是否具有适当的文档覆盖率？其他地方的文档是否需要更新？
• 您喜欢这种实现吗？您能想到更简洁或更快的实现他们更改部分的方法吗？

一旦您对拉取请求包含良好的更改感到满意，请在 GitHub 问题中发表评论，表明您的发现。您的评论应表明您喜欢更改以及您喜欢更改的什么。例如

我喜欢你在 generate_finder_sql 中重构代码的方式 - 非常棒。测试看起来也不错。

如果您的评论只是“+1”，那么其他审阅者很可能不会太认真对待它。表明您花时间审阅了拉取请求。

3 贡献到 Rails 文档

Ruby on Rails 有两套主要文档：指南，帮助您了解 Ruby on Rails，以及 API，充当参考。

您可以通过使 Rails 指南或 API 参考更连贯、一致或易读，添加缺失的信息，更正事实错误，修复错别字，或将它们更新为最新的 edge Rails，来帮助改进它们。

为此，请对 Rails 指南源文件（位于 GitHub 上的 此处）或源代码中的 RDoc 注释进行更改。然后打开一个拉取请求以将您的更改应用到主分支。

在您的拉取请求标题中使用“[ci skip]”来避免为文档更改运行 CI 构建。

打开 PR 后，将部署文档预览以方便审阅和协作。在拉取请求页面底部，您应该会看到一个状态检查列表，查找“buildkite/docs-preview”并单击“详细信息”。

这将带您到 Buildkite 构建页面。如果作业成功，在作业列表上方将有一个包含指向生成的 API 和指南链接的注释。

在处理文档时，请考虑 API 文档指南 和 Ruby on Rails 指南指南。

4 翻译 Rails 指南

我们很乐意让志愿者翻译 Rails 指南。只需遵循以下步骤

• 分叉 https://github.com/rails/rails。
• 为您的语言添加一个源文件夹，例如：guides/source/it-IT 用于意大利语。
• 将 guides/source 的内容复制到您的语言目录并进行翻译。
• 请勿翻译 HTML 文件，因为它们是自动生成的。

请注意，翻译不会提交到 Rails 代码库；您的工作保存在您的分叉中，如上所述。这是因为实际上，通过补丁进行的文档维护仅在英语中是可持续的。

要生成 HTML 格式的指南，您需要安装指南依赖项，cd 到 guides 目录，然后运行（例如，对于 it-IT）

$ BUNDLE_ONLY=default:doc bundle install
$ cd guides/
$ BUNDLE_ONLY=default:doc bundle exec rake guides:generate:html GUIDES_LANGUAGE=it-IT

这将在 output 目录中生成指南。

5 贡献到 Rails 代码

5.1 设置开发环境

要从提交错误转向帮助解决现有问题或为 Ruby on Rails 贡献您自己的代码，您必须能够运行其测试套件。在本指南的这一部分中，您将学习如何在计算机上设置测试。

5.1.1 使用 GitHub Codespaces

如果您是启用了 Codespaces 的组织的成员，您可以将 Rails 分叉到该组织并使用 GitHub 上的 Codespaces。Codespace 将使用所有必需的依赖项进行初始化，并允许您运行所有测试。

5.1.2 使用 VS Code 远程容器

如果您安装了 Visual Studio Code 和 Docker，则可以使用 VS Code 远程容器插件。该插件将读取存储库中的 .devcontainer 配置并在本地构建 Docker 容器。

5.1.3 使用 Dev Container CLI

或者，安装了 Docker 和 npm 后，您可以运行 Dev Container CLI 来利用来自命令行的 .devcontainer 配置。

$ npm install -g @devcontainers/cli
$ cd rails
$ devcontainer up --workspace-folder .
$ devcontainer exec --workspace-folder . bash

5.1.4 使用 rails-dev-box

也可以使用 rails-dev-box 来准备开发环境。但是，rails-dev-box 使用 Vagrant 和 Virtual Box，它们在使用 Apple 硅芯片的 Mac 上将无法使用。

5.1.5 本地开发

当您无法使用 GitHub Codespaces 时，请参阅 另一份指南，了解如何设置本地开发。这被认为是困难的方法，因为安装依赖项可能是特定于操作系统的。

5.2 克隆 Rails 代码库

要能够贡献代码，您需要克隆 Rails 代码库

$ git clone https://github.com/rails/rails.git

并创建一个专用分支

$ cd rails
$ git checkout -b my_new_branch

您使用的名称并不重要，因为此分支仅存在于您的本地计算机和您在 GitHub 上的个人代码库中。它不会成为 Rails Git 代码库的一部分。

5.3 bundle install

安装所需的 gems。

$ bundle install

5.4 在本地分支上运行应用程序

如果您需要一个虚拟 Rails 应用程序来测试更改，rails new 的 --dev 标志会生成一个使用本地分支的应用程序

$ cd rails
$ bundle exec rails new ~/my-test-app --dev

在 ~/my-test-app 中生成的应用程序针对您的本地分支运行，特别是，在服务器重启后会看到任何修改。

对于 JavaScript 包，您可以使用 yarn link 在生成的应用程序中源代码您的本地分支

$ cd rails/activestorage
$ yarn link
$ cd ~/my-test-app
$ yarn link "@rails/activestorage"

5.5 编写您的代码

现在该编写一些代码了！在为 Rails 进行更改时，请记住以下几点

• 遵循 Rails 样式和约定。
• 使用 Rails 成语和助手。
• 包含在没有您的代码的情况下会失败，但在有您的代码的情况下会通过的测试。
• 更新（周围的）文档、其他地方的示例和指南：任何受您的贡献影响的内容。
• 如果更改添加、删除或更改功能，请务必包含 CHANGELOG 条目。如果您的更改是错误修复，则不需要 CHANGELOG 条目。

5.5.1 遵循编码约定

Rails 遵循一组简单的编码样式约定

• 两个空格，没有制表符（用于缩进）。
• 没有尾随空格。空行不应包含任何空格。
• 缩进，并且在 private/protected 之后没有空行。
• 使用 Ruby >= 1.9 语法来表示哈希。优先使用 { a: :b } 而不是 { :a => :b }。
• 优先使用 &&/|| 而不是 and/or。
• 对于类方法，优先使用 class << self 而不是 self.method。
• 使用 my_method(my_arg)，而不是 my_method( my_arg ) 或 my_method my_arg。
• 使用 a = b，而不是 a=b。
• 使用 assert_not 方法而不是 refute。
• 对于单行代码块，优先使用 method { do_stuff } 而不是 method{do_stuff}。
• 遵循您在源代码中看到的现有约定。

以上只是指导原则，请根据您的最佳判断来使用它们。

此外，我们还定义了 RuboCop 规则来规范一些编码规范。您可以在提交拉取请求之前，在本地对修改后的文件运行 RuboCop。

$ bundle exec rubocop actionpack/lib/action_controller/metal/strong_parameters.rb
Inspecting 1 file
.

1 file inspected, no offenses detected

5.6 对代码进行基准测试

对于可能影响性能的更改，请对代码进行基准测试并衡量影响。请共享您使用的基准测试脚本以及结果。您应该考虑将此信息包含在您的提交消息中，以便未来的贡献者可以轻松验证您的发现并确定它们是否仍然相关。（例如，Ruby 虚拟机未来的优化可能会使某些优化变得不必要。）

当针对您关心的特定场景进行优化时，很容易降低其他常见情况的性能。因此，您应该针对代表性场景列表测试您的更改，理想情况下，这些场景是从现实世界中的生产应用程序中提取的。

您可以使用 基准测试模板 作为起点。它包含使用 benchmark-ips gem 设置基准测试的样板代码。该模板旨在测试可以内联到脚本中的相对独立的更改。

5.7 运行测试

在 Rails 中，在推送更改之前运行完整的测试套件并不常见。特别是 railties 测试套件需要很长时间才能运行，如果源代码安装在 /vagrant 中（如使用 rails-dev-box 的推荐工作流程中），则会花费更长的时间。

作为折衷方案，测试您的代码显然会影响到的部分，如果更改不在 railties 中，则运行受影响组件的整个测试套件。如果所有测试都通过，那就足以提出您的贡献。我们有 Buildkite 作为安全网，以防万一在其他地方出现意外故障。

5.7.1 整个 Rails

要运行所有测试，请执行以下操作

$ cd rails
$ bundle exec rake test

5.7.2 特定组件

您可以仅针对特定组件（例如，Action Pack）运行测试。例如，要运行 Action Mailer 测试，请执行以下操作

$ cd actionmailer
$ bin/test

5.7.3 特定目录

您可以仅针对特定组件（例如，Active Storage 中的模型）的特定目录运行测试。例如，要运行 /activestorage/test/models 中的测试，请执行以下操作

$ cd activestorage
$ bin/test models

5.7.4 特定文件

您可以运行特定文件的测试

$ cd actionview
$ bin/test test/template/form_helper_test.rb

5.7.5 运行单个测试

您可以使用 -n 选项按名称运行单个测试

$ cd actionmailer
$ bin/test test/mail_layout_test.rb -n test_explicit_class_layout

5.7.6 特定行

确定名称并不总是容易，但如果您知道测试开始处的行号，此选项适合您

$ cd railties
$ bin/test test/application/asset_debugging_test.rb:69

5.7.7 特定行范围

类似的测试通常在附近的位置定义。您可以在特定行范围内运行测试。

$ cd railties
$ bin/test test/application/asset_debugging_test.rb:69-100

5.7.8 使用特定种子运行测试

测试执行使用随机化种子进行随机化。如果您遇到随机测试失败，可以通过专门设置随机化种子来更准确地重现失败的测试场景。

运行组件的所有测试

$ cd actionmailer
$ SEED=15002 bin/test

运行单个测试文件

$ cd actionmailer
$ SEED=15002 bin/test test/mail_layout_test.rb

5.7.9 按顺序运行测试

Action Pack 和 Action View 单元测试默认情况下并行运行。如果您遇到随机测试失败，可以设置随机化种子并让这些单元测试按顺序运行，方法是设置 PARALLEL_WORKERS=1

$ cd actionview
$ PARALLEL_WORKERS=1 SEED=53708 bin/test test/template/test_case_test.rb

5.7.10 测试 Active Record

首先，创建您需要的数据库。您可以在 activerecord/test/config.example.yml 中找到所需的表名、用户名和密码列表。

对于 MySQL 和 PostgreSQL，运行以下命令就足够了

$ cd activerecord
$ bundle exec rake db:mysql:build

或者

$ cd activerecord
$ bundle exec rake db:postgresql:build

对于 SQLite3，则不需要这样做。

这是您仅针对 SQLite3 运行 Active Record 测试套件的方式

$ cd activerecord
$ bundle exec rake test:sqlite3

现在，您可以像针对 sqlite3 一样运行测试。这些任务分别是

$ bundle exec rake test:mysql2
$ bundle exec rake test:trilogy
$ bundle exec rake test:postgresql

最后，

$ bundle exec rake test

现在将依次运行这三个任务。

您也可以单独运行任何单个测试

$ ARCONN=mysql2 bundle exec ruby -Itest test/cases/associations/has_many_associations_test.rb

要针对所有适配器运行单个测试，请使用

$ bundle exec rake TEST=test/cases/associations/has_many_associations_test.rb

您也可以调用 test_jdbcmysql、test_jdbcsqlite3 或 test_jdbcpostgresql。有关运行更多针对性数据库测试的信息，请参见文件 activerecord/RUNNING_UNIT_TESTS.rdoc。

5.7.11 使用调试器进行测试

要使用外部调试器（pry、byebug 等），请安装调试器并像往常一样使用它。如果遇到调试器问题，请按顺序运行测试，方法是设置 PARALLEL_WORKERS=1 或使用 -n test_long_test_name 运行单个测试。

如果针对生成器运行测试，您需要设置 RAILS_LOG_TO_STDOUT=true，以便调试工具正常工作。

RAILS_LOG_TO_STDOUT=true ./bin/test test/generators/actions_test.rb

5.8 警告

测试套件在启用警告的情况下运行。理想情况下，Ruby on Rails 不应该发出任何警告，但可能存在一些警告，以及来自第三方库的一些警告。请忽略（或修复！）它们（如果有），并提交不会发出新警告的补丁。

如果引入了警告，Rails CI 将会引发错误。要在本地实现相同的行为，在运行测试套件时设置 RAILS_STRICT_WARNINGS=1。

5.9 更新文档

Ruby on Rails 指南 提供了 Rails 功能的高级概述，而 API 文档 则深入介绍了具体细节。

如果您的 PR 添加了新功能或更改了现有功能的行为，请检查相关文档并根据需要更新或添加内容。

例如，如果您修改 Active Storage 的图像分析器以添加一个新的元数据字段，您应该更新 Active Storage 指南中的 分析文件 部分，以反映这一点。

5.10 更新 CHANGELOG

CHANGELOG 是每个版本的重要组成部分。它保留了每个 Rails 版本的更改列表。

如果您添加或删除功能、添加弃用通知，则应将条目添加到您修改的框架的 CHANGELOG 的顶部。重构、次要错误修复和文档更改通常不应添加到 CHANGELOG 中。

CHANGELOG 条目应总结更改的内容，并应以作者姓名结尾。如果您需要更多空间，可以使用多行，并且可以添加缩进 4 个空格的代码示例。如果更改与特定问题相关，您应该添加该问题的编号。以下是一个 CHANGELOG 条目示例

*   Summary of a change that briefly describes what was changed. You can use multiple
    lines and wrap them at around 80 characters. Code examples are ok, too, if needed:

        class Foo
          def bar
            puts 'baz'
          end
        end

    You can continue after the code example, and you can attach the issue number.

    Fixes #1234.

    *Your Name*

5.11 突破性变更

任何可能破坏现有应用程序的更改都被认为是突破性变更。为了简化 Rails 应用程序的升级，突破性变更需要一个弃用周期。

5.11.1 删除行为

如果您的突破性变更删除了现有行为，您首先需要添加一个弃用警告，同时保留现有行为。

例如，假设您要从 ActiveRecord::Base 中删除一个公共方法。如果主分支指向未发布的 7.0 版本，则 Rails 7.0 需要显示一个弃用警告。这确保了升级到任何 Rails 7.0 版本的任何人都会看到弃用警告。在 Rails 7.1 中，可以删除该方法。

您可以添加以下弃用警告

def deprecated_method
  ActiveRecord.deprecator.warn(<<-MSG.squish)
    `ActiveRecord::Base.deprecated_method` is deprecated and will be removed in Rails 7.1.
  MSG
  # Existing behavior
end

5.11.2 更改行为

如果您的突破性变更更改了现有行为，您需要添加一个框架默认值。框架默认值通过允许应用程序逐个切换到新默认值来简化 Rails 升级。

要实现新的框架默认值，首先通过在目标框架上添加一个访问器来创建一个配置。将默认值设置为现有行为，以确保在升级过程中不会出现任何问题。

module ActiveJob
  mattr_accessor :existing_behavior, default: true
end

新的配置允许您有条件地实现新行为

def changed_method
  if ActiveJob.existing_behavior
    # Existing behavior
  else
    # New behavior
  end
end

要设置新的框架默认值，请在 Rails::Application::Configuration#load_defaults 中设置新值

def load_defaults(target_version)
  case target_version.to_s
  when "7.1"
    # ...
    if respond_to?(:active_job)
      active_job.existing_behavior = false
    end
    # ...
  end
end

为了简化升级，需要将新的默认值添加到 new_framework_defaults 模板中。添加一个注释掉的节，设置新值

# new_framework_defaults_8_0.rb.tt

# Rails.application.config.active_job.existing_behavior = false

作为最后一步，将新配置添加到 configuration.md 中的配置指南中

#### `config.active_job.existing_behavior

| Starting with version | The default value is |
| --------------------- | -------------------- |
| (original)            | `true`               |
| 7.1                   | `false`              |

5.12 忽略编辑器/IDE 创建的文件

某些编辑器和 IDE 会在 rails 文件夹中创建隐藏文件或文件夹。与其在每次提交时手动排除这些文件或将它们添加到 Rails 的 .gitignore 中，不如将它们添加到您自己的 全局 gitignore 文件 中。

5.13 更新 Gemfile.lock

某些更改需要依赖项升级。在这些情况下，请确保运行 bundle update 以获取依赖项的正确版本，并在更改中提交 Gemfile.lock 文件。

5.14 提交更改

当您对计算机上的代码感到满意时，需要将更改提交到 Git

$ git commit -a

这将启动您的编辑器以编写提交消息。完成后，保存并关闭以继续。

格式良好且描述性的提交消息对其他人理解更改的原因非常有帮助，因此请花时间编写它。

一个好的提交消息看起来像这样

Short summary (ideally 50 characters or less)

More detailed description, if necessary. Each line should wrap at
72 characters. Try to be as descriptive as you can. Even if you
think that the commit content is obvious, it may not be obvious
to others. Add any description that is already present in the
relevant issues; it should not be necessary to visit a webpage
to check the history.

The description section can have multiple paragraphs.

Code examples can be embedded by indenting them with 4 spaces:

    class ArticlesController
      def index
        render json: Article.limit(10)
      end
    end

You can also add bullet points:

- make a bullet point by starting a line with either a dash (-)
  or an asterisk (*)

- wrap lines at 72 characters, and indent any additional lines
  with 2 spaces for readability

5.15 更新分支

在您工作时，很可能 main 中发生了其他更改。要获取 main 中的新更改，请执行以下操作

$ git checkout main
$ git pull --rebase

现在，将您的补丁重新应用到最新的更改之上

$ git checkout my_new_branch
$ git rebase main

没有冲突？测试仍然通过？更改对您来说仍然合理？然后将重新基于的更改推送到 GitHub

$ git push --force-with-lease

我们不允许在 rails/rails 存储库基础上进行强制推送，但您可以强制推送至您的 fork。在重新基于时，这是必需的，因为历史记录已更改。

5.16 fork

导航到 Rails GitHub 存储库，然后按右上角的“Fork”。

将新远程添加到您本地机器上的本地存储库

$ git remote add fork https://github.com/<your username>/rails.git

您可能已经从 rails/rails 克隆了本地存储库，或者可能已经从您的 fork 存储库克隆了本地存储库。以下 git 命令假设您已经创建了一个指向 rails/rails 的“rails”远程。

$ git remote add rails https://github.com/rails/rails.git

从官方存储库下载新提交和分支

$ git fetch rails

合并新内容

$ git checkout main
$ git rebase rails/main
$ git checkout my_new_branch
$ git rebase rails/main

更新您的 fork

$ git push fork main
$ git push fork my_new_branch

5.17 打开拉取请求

导航到您刚刚推送到其中的 Rails 存储库（例如，https://github.com/your-user-name/rails），然后单击顶部栏（代码上方）中的“Pull Requests”。在下一页中，单击右上角的“New pull request”。

拉取请求应针对基础存储库 rails/rails 和分支 main。头部存储库将是您的工作（your-user-name/rails），分支将是您为分支指定的任何名称。准备就绪后，单击“create pull request”。

确保您引入的变更集已包含。使用提供的拉取请求模板填写有关您潜在补丁的一些详细信息。完成后，点击“创建拉取请求”。

5.18 获取反馈

大多数拉取请求会在合并之前经历几次迭代。不同的贡献者有时会有不同的意见，而且补丁通常需要修改才能合并。

Rails 的一些贡献者启用了 GitHub 的电子邮件通知，而另一些则没有。此外，（几乎）所有在 Rails 上工作的人都是志愿者，因此您可能需要几天时间才能收到有关拉取请求的第一个反馈。不要绝望！有时很快，有时很慢。这就是开源生活。

如果一周过去了，您还没有收到任何消息，您可能需要尝试推动一下。您可以使用 Ruby on Rails Discord 服务器 中的“贡献”频道，或者 rubyonrails-core 讨论版。您也可以在拉取请求中留下另一条评论。最好避免直接ping个别维护者，因为我们的带宽有限，可能无法查看您的PR。

在等待拉取请求的反馈时，打开几个其他拉取请求，并给予其他人一些反馈！他们会像您欣赏对补丁的反馈一样欣赏您的反馈。

请注意，只有核心团队和提交者团队被允许合并代码更改。如果有人给出反馈并“批准”您的更改，他们可能没有能力或最终决定权来合并您的更改。

5.19 根据需要进行迭代

您得到的反馈可能会建议进行更改，这完全有可能。不要气馁：为活跃的开源项目做出贡献的全部意义在于利用社区的知识。如果人们鼓励您调整代码，那么值得进行调整并重新提交。如果反馈是您的代码不会被合并，您仍然可以考虑将其作为 gem 发布。

5.19.1 合并提交

我们可能会要求您做的一件事是“合并您的提交”，这将把您的所有提交合并成一个提交。我们更喜欢单个提交的拉取请求。这使得将更改回移植到稳定分支更容易，合并使得撤销不良提交更容易，并且 git 历史记录更容易跟踪。Rails 是一个大型项目，一堆无关的提交会增加很多噪音。

$ git fetch rails
$ git checkout my_new_branch
$ git rebase -i rails/main

< Choose 'squash' for all of your commits except the first one. >
< Edit the commit message to make sense, and describe all your changes. >

$ git push fork my_new_branch --force-with-lease

您应该能够刷新 GitHub 上的拉取请求，并看到它已更新。

5.19.2 更新拉取请求

有时您会被要求对您已经提交的代码进行一些更改。这可能包括修改现有提交。在这种情况下，Git 将不允许您推送更改，因为推送的分支和本地分支不匹配。与其打开一个新的拉取请求，不如像之前在合并提交部分描述的那样，将更改强制推送到 GitHub 上的分支。

$ git commit --amend
$ git push fork my_new_branch --force-with-lease

这将使用您的新代码更新 GitHub 上的分支和拉取请求。通过使用 --force-with-lease 强制推送，git 将比典型的 -f 更安全地更新远程，后者可能会删除您还没有的远程工作。

5.20 Ruby on Rails 的旧版本

如果您想将修复程序添加到比下一个版本更早的 Ruby on Rails 版本中，您需要设置并切换到您自己的本地跟踪分支。以下是如何切换到 7-0-stable 分支的示例

$ git branch --track 7-0-stable rails/7-0-stable
$ git checkout 7-0-stable

5.20.1 回移植

合并到 main 的更改 предназначены для следующего основного выпуска Rails. Иногда может быть полезно распространить изменения обратно на стабильные ветки для включения в релизы поддержки. Как правило, исправления безопасности и исправления ошибок являются хорошими кандидатами для обратной передачи, в то время как новые функции и исправления, которые меняют ожидаемое поведение, не будут приняты. В случае сомнений лучше проконсультироваться с членом команды Rails, прежде чем обратную передачу изменений, чтобы избежать пустой траты времени.

首先，确保您的 main 分支是最新的。

$ git checkout main
$ git pull --rebase

检出您要回移植到的分支，例如 7-0-stable，并确保它是最新的

$ git checkout 7-0-stable
$ git reset --hard origin/7-0-stable
$ git checkout -b my-backport-branch

如果您要回移植合并的拉取请求，请找到合并的提交并 cherry-pick 它

$ git cherry-pick -m1 MERGE_SHA

修复 cherry-pick 中发生的任何冲突，推送您的更改，然后打开一个指向您要回移植到的稳定分支的 PR。如果您有一组更复杂的更改，cherry-pick 文档可以提供帮助。

6 Rails 贡献者

所有贡献都将在 Rails 贡献者 中获得认可。