貢獻於 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 問題中。如果您希望看到將新功能新增至 Ruby on Rails，您需要自己編寫程式碼，或說服其他人與您合作編寫程式碼。在本指南的稍後部分，您將找到提出 Ruby on Rails 修補程式的詳細說明。如果您在 GitHub 問題中輸入沒有程式碼的願望清單項目，您會發現它在審閱後很快被標記為「無效」。

有時候，「錯誤」和「功能」之間的界線很難劃分。一般而言，功能是指任何新增行為的事物，而錯誤是指任何導致不正確行為的事物。有時，核心團隊必須做出判斷。也就是說，區別通常決定了您的變更會隨著哪個修補程式發佈；我們喜歡功能提交！它們只是不會回溯到維護分支。

如果您希望在進行修補程式之前取得有關功能想法的回饋，請在 rails-core 討論區中開始討論。您可能會沒有收到任何回應，這表示大家都漠不關心。您可能會找到也有興趣建構該功能的人。您可能會收到「這不會被接受」的回應。但這是討論新想法的適當場所。GitHub 問題並不是新功能所需的有時冗長且複雜討論的特別好場所。

2 協助解決現有的問題

除了回報問題外，您還可以透過提供有關問題的回饋來協助核心團隊解決現有的問題。如果您是 Rails 核心開發的新手，提供回饋將有助於您熟悉程式碼庫和流程。

如果您查看 GitHub Issues 中的問題列表，您會發現已經有很多問題需要處理。您能做些什麼呢？實際上，您可以做很多事情

2.1 驗證錯誤報告

首先，驗證錯誤報告會有幫助。您可以在自己的電腦上重現所報告的問題嗎？如果可以，您可以在問題中添加評論，說明您也遇到了相同的問題。

如果問題非常模糊，您可以幫助將其縮小到更具體的問題嗎？也許您可以提供更多資訊來重現錯誤，或者您可以刪除不必要的步驟，這些步驟對於示範問題來說是不需要的。

如果您發現沒有測試的錯誤報告，那麼貢獻一個失敗的測試會非常有幫助。這也是探索原始碼的好方法：查看現有的測試檔案會教您如何編寫更多測試。最好以修補程式的形式貢獻新測試，如稍後在貢獻 Rails 程式碼章節中所述。

任何能使錯誤報告更簡潔或更容易重現的行為，都有助於那些嘗試編寫程式碼來修正這些錯誤的人，無論您最終是否自己編寫程式碼。

2.2 測試修補程式

您也可以透過檢查透過 GitHub 提交給 Ruby on Rails 的 pull request 來提供幫助。為了應用某人的變更，首先要建立一個專用分支

$ git checkout -b testing_branch

然後，您可以使用他們的遠端分支來更新您的程式碼庫。例如，假設 GitHub 使用者 JohnSmith 已 fork 並推送至位於 https://github.com/JohnSmith/rails 的主題分支「orange」。

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

除了將他們的遠端新增到您的 checkout 之外，另一種方法是使用 GitHub CLI 工具 來 checkout 他們的 pull request。

在應用他們的分支後，測試一下！以下是一些需要考慮的事項

• 變更是否真的有效？
• 您對測試感到滿意嗎？您能否理解它們正在測試的內容？是否有任何測試遺漏？
• 它是否有適當的文件涵蓋範圍？是否應更新其他地方的文件？
• 您喜歡這個實作嗎？您能否想到一個更好或更快的方法來實作他們變更的一部分？

當您確信 pull request 包含一個好的變更時，請在 GitHub 問題上評論說明您的發現。您的評論應該表明您喜歡這個變更以及您喜歡它的原因。類似這樣

我喜歡您在 generate_finder_sql 中重組程式碼的方式 - 更好多了。測試看起來也不錯。

如果您的評論只是簡單地寫「+1」，那麼其他審閱者很可能不會太認真看待。請表明您花時間審閱了 pull request。

3 貢獻 Rails 文件

Ruby on Rails 有兩組主要的文件：指南，可幫助您了解 Ruby on Rails，以及 API，作為參考。

您可以透過使其更連貫、一致或易於閱讀、新增遺漏的資訊、更正事實錯誤、修正拼字錯誤或使其與最新的 edge Rails 同步來幫助改進 Rails 指南或 API 參考。

要做到這一點，請變更 Rails 指南原始檔案（位於 GitHub 上的此處）或原始碼中的 RDoc 註解。然後開啟一個 pull request，以將您的變更應用到主要分支。

在您的 pull request 標題中使用 [ci skip]，以避免為文件變更執行 CI 建置。

一旦您開啟 PR，將部署文件預覽，以便輕鬆審閱和協作。在 Pull Request 頁面的底部，您應該會看到一個狀態檢查清單，尋找 buildkite/docs-preview 並點擊「詳細資料」。

這會將您帶到 Buildkite 建置頁面。如果作業成功，在作業清單上方會出現一個帶有指向產生 API 和指南的連結的註解。

在使用文件時，請考慮API 文件指南和Ruby on Rails 指南指南。

4 翻譯 Rails 指南

我們很高興有志願者翻譯 Rails 指南。只需按照以下步驟操作

• Fork https://github.com/rails/rails。
• 為您的語言新增一個來源資料夾，例如：義大利語的 guides/source/it-IT。
• 將 guides/source 的內容複製到您的語言目錄中並翻譯它們。
• 請勿翻譯 HTML 檔案，因為它們是自動產生的。

請注意，翻譯不會提交到 Rails 儲存庫；您的工作會如上所述存在於您的 fork 中。這是因為，在實務上，透過修補程式進行文件維護僅在英文中是可持續的。

要以 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

如果您是已啟用 codespace 的組織的成員，您可以將 Rails fork 到該組織中，並在 GitHub 上使用 codespace。Codespace 將會使用所有必要的相依性進行初始化，並允許您執行所有測試。

5.1.2 使用 VS Code Remote Containers

如果您已安裝 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 Silicon 的 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

安裝所需的 gem。

$ 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 慣用語和 helper。
• 包含在沒有您的程式碼的情況下會失敗，並且在有的情況下會通過的測試。
• 更新（周圍的）文件、其他地方的範例和指南：任何受您貢獻影響的內容。
• 如果變更新增、移除或變更功能，請務必包含 CHANGELOG 項目。如果您的變更是錯誤修復，則不需要 CHANGELOG 項目。

5.5.1 遵循程式碼慣例

Rails 遵循一組簡單的程式碼風格慣例

• 兩個空格，沒有 tab（用於縮排）。
• 沒有尾隨空格。空白行不應有任何空格。
• 在 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 規則來整理我們的一些程式碼慣例。您可以在提交 pull request 之前，在本機針對您修改的檔案執行 RuboCop

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

1 file inspected, no offenses detected

5.6 基準測試您的程式碼

對於可能影響效能的變更，請基準測試您的程式碼並測量其影響。請分享您使用的基準測試指令碼以及結果。您應該考慮在您的 commit 訊息中包含此資訊，以便未來的貢獻者可以輕鬆驗證您的發現，並確定它們是否仍然相關。（例如，Ruby VM 中未來的最佳化可能會使某些最佳化變得不必要。）

當您針對您關心的特定案例進行最佳化時，很容易會讓其他常見案例的效能倒退。因此，您應該針對一組具代表性的案例測試您的變更，理想情況下是從真實世界的生產應用程式中提取的案例。

你可以使用基準測試範本作為起點。它包含了使用 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 中的 models）執行測試。例如，要執行 /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 使用特定 Seed 執行測試

測試執行會使用隨機化 seed 進行隨機化。如果你遇到隨機測試失敗的情況，你可以透過明確設定隨機化 seed 來更準確地重現失敗的測試情境。

執行元件的所有測試

$ cd actionmailer
$ SEED=15002 bin/test

執行單一測試檔案

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

5.7.9 依序執行測試

Action Pack 和 Action View 單元測試預設會並行執行。如果你遇到隨機測試失敗的情況，你可以設定隨機化 seed，並透過設定 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 儲存庫基礎上強制推送，但你可以強制推送到你的分支。在重新設定基底時，這是必要的，因為歷史記錄已變更。

5.16 分支

導覽至 Rails GitHub 儲存庫，然後按一下右上角的「分支」。

將新的遠端新增至本機電腦上的本機儲存庫：

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

你可能已從 rails/rails 克隆了本機儲存庫，或者可能已從你的分支儲存庫克隆了本機儲存庫。以下 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

更新你的分支：

$ git push fork main
$ git push fork my_new_branch

5.17 開啟提取請求

導覽至你剛推送到的 Rails 儲存庫（例如，https://github.com/your-user-name/rails），然後按一下頂端列（程式碼上方）中的「提取請求」。在下一個頁面上，按一下右上角的「新提取請求」。

提取請求應以基本儲存庫 rails/rails 和分支 main 為目標。頭部儲存庫將會是你的工作（your-user-name/rails），而分支將會是你給予分支的任何名稱。準備好後，按一下「建立提取請求」。

確認你導入的變更集已包含在內。使用提供的提取請求範本填寫有關你的潛在修補程式的一些詳細資訊。完成後，按一下「建立提取請求」。

5.18 取得一些回饋

大多數提取請求在合併之前都會經過幾次反覆運算。不同的貢獻者有時會有不同的意見，而且通常需要修訂修補程式才能合併。

有些 Rails 貢獻者開啟了來自 GitHub 的電子郵件通知，但其他貢獻者則沒有。此外，（幾乎）所有在 Rails 上工作的人都是志工，因此你可能需要幾天才能收到提取請求的第一個回饋。不要絕望！有時很快；有時很慢。這就是開放原始碼的生活。

如果超過一週您都沒有收到任何回覆，您可能需要嘗試推動一下進度。您可以利用 Ruby on Rails Discord 伺服器 中的貢獻頻道，或是 rubyonrails-core 討論區 來進行。您也可以在 pull request 上再次留言。最好避免直接 ping 個別維護者，因為我們的時間有限，可能無法立即查看您的 PR。

在等待您的 pull request 回饋時，不妨開啟一些其他的 pull request 並給予其他人回饋！他們會像您感謝他們對您的程式碼修正提供回饋一樣感謝您。

請注意，只有核心團隊和提交者團隊才有權合併程式碼變更。如果有人給予回饋並「批准」您的變更，他們可能沒有合併您變更的權限或最終決定權。

5.19 視情況迭代

您獲得的回饋很可能會建議您進行變更。不要灰心：貢獻給活躍的開源專案的重點就是利用社群的知識。如果有人鼓勵您調整程式碼，那麼就值得進行調整並重新提交。如果回饋是您的程式碼不會被合併，您仍然可以考慮將其作為 gem 發布。

5.19.1 合併 Commit

我們可能會要求您執行的一件事是「合併您的 commit」，這會將您的所有 commit 合併為單一 commit。我們偏好單一 commit 的 pull request。這樣可以更輕鬆地將變更移植到穩定分支、合併操作使還原錯誤的 commit 更容易，而且 git 歷史記錄也更容易追蹤。Rails 是一個大型專案，大量不必要的 commit 會增加許多雜訊。

$ 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 上的 pull request，並看到它已更新。

5.19.2 更新 Pull Request

有時您會被要求對已提交的程式碼進行一些變更。這可能包括修改現有的 commit。在這種情況下，Git 將不允許您推送變更，因為已推送的分支和本機分支不匹配。您可以選擇強制推送您的分支到 GitHub，如先前合併 commit 章節中所述，而不是開啟新的 pull request。

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

這將使用您的新程式碼更新 GitHub 上的分支和 pull request。透過使用 --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

如果您要向後移植已合併的 pull request，請找到合併的 commit 並進行 cherry-pick

$ git cherry-pick -m1 MERGE_SHA

修正 cherry-pick 中發生的任何衝突，推送您的變更，然後開啟一個指向您要向後移植的穩定分支的 PR。如果您有更複雜的變更集，cherry-pick 文件可以提供協助。

6 Rails 貢獻者

所有貢獻都會在 Rails 貢獻者 中獲得認可。