Chapters1 報告問題
Rails 上的 Ruby 使用 GitHub 問題 Tracking 到 track 問題（主要是新程式碼的錯誤和貢獻）。如果您在 Rails 上的 Ruby 中發現了錯誤，請從這裡開始。您需要建立一個（免費）GitHub 帳戶來提交問題、評論問題或建立拉取請求。
在 Rails 上最新發布的 Ruby 版本中的錯誤可能會得到最多的關注。此外，Rails 核心團隊總是對那些可以花時間測試 edge Rails（目前正在開發的 Rails 版本的程式碼）的人的反饋感興趣。在本指南的後面，您將瞭解如何獲取邊緣 Rails 進行測試。
1.1 建立錯誤報告
如果您在 Rails 上的 Ruby 中發現了一個不是安全風險的問題，請在 GitHub 上搜索 問題，以防它已被報告。如果您找不到任何解決您發現的問題的開放 GitHub 問題，您的下一步將是 開啟一個新問題。 （有關報告安全問題，請參閱下一節。）
您的問題報告應至少包含問題的標題和清晰的描述。您應該包含儘可能多的相關資訊和演示問題的程式碼示例。包含一個測試預期行為的失敗單元測試會更好。你的目標應該是讓你自己 - 和其他人 - 更容易重現錯誤並找出修復方法。
那麼，不要抱有希望！除非您有“程式碼紅色，關鍵任務，世界即將終結”之類的錯誤，否則不要期望問題報告會自動看到任何活動或有人會跳出來修復它。您正在建立此問題報告，以便遇到相同問題的其他人可以確認該錯誤並與您合作修復它。
1.2 建立一個可執行的測試用例
有辦法重現您的問題將有助於人們確認、調查並最終解決您的問題。您可以透過提供一個可執行的測試用例來做到這一點。為了簡化此過程，我們準備了幾個錯誤報告模板供您用作起點：
- Active Record（models，資料庫）問題的模板：gem / main
- 用於測試 Active Record (migration) 問題的模板：gem / main
- Action Pack（controllers，路由）問題的模板：gem / main
- Active Job 問題模板：gem / main
- Active Storage 問題模板：gem / main
- Action Mailbox 問題模板：gem / main
- 其他問題的通用模板：gem / main
這些模板包括樣板程式碼，用於針對 Rails (*_gem.rb) 的釋出版本或邊緣 Rails (*_main.rb) 設定測試用例。
將相應模板的內容複製到 .rb 檔案中，並進行必要的更改以演示問題。您可以透過在終端中執行 ruby the_file.rb 來執行它。如果一切順利，您應該會看到您的測試用例失敗。
然後，您可以將您的可執行測試用例作為 gist 共享或將內容貼上到問題描述中。
1.3 安全問題特殊處理
請不要在公共 GitHub 問題報告中報告安全漏洞。 Rails 安全策略頁面 詳細說明了安全問題要遵循的程式。
1.4 功能請求呢？
請不要將“功能請求”項放入 GitHub 問題。如果有新的 您希望在 Rails 上看到新增到 Ruby 的功能，您需要編寫 自己編寫程式碼 - 或說服其他人與您合作編寫程式碼。 在本指南的後面，您將找到有關向 Rails 上的 Ruby。如果你在 GitHub Issues 中輸入一個沒有程式碼的願望清單專案，你 可以期望它在 reviewed 後立即被標記為“無效”。
有時，“錯誤”和“功能”之間的界限很難劃清。 一般來說，一個特性是任何增加新行為的東西，而一個錯誤 是導致錯誤行為的任何事情。有時，核心團隊會有 作出判斷。也就是說，差別通常決定了哪個 釋出您的更改的補丁；我們喜歡提交功能！他們只是 不會被反向移植到維護分支。
如果您想在開始工作之前就某個功能的想法獲得反饋 一個補丁，請發郵件到rails-core mailing 列表。你 可能沒有得到回應，這意味著每個人都無動於衷。你可能會發現 也有興趣構建該功能的人。你可能會得到一個“這個 不會被接受”。但這是討論新想法的合適場所。GitHub 問題不是一個特別好的地方，有時很長而且涉及 討論新功能需要。
2 幫助解決現有問題
除了報告問題之外，您還可以透過提供有關問題的反饋來幫助核心團隊解決現有問題。如果您不熟悉 Rails 核心開發，這可能是邁出第一步的好方法，您將熟悉程式碼庫和流程。
如果您檢視 GitHub 問題中的 問題列表，您會發現很多問題已經需要關注。你能對這些做什麼？相當多，實際上：
2.1 驗證錯誤報告
首先，它有助於驗證錯誤報告。您能在您的計算機上重現報告的問題嗎？如果是這樣，您可以對問題新增評論，說明您看到了相同的內容。
如果問題非常模糊，您能否幫助將其縮小到更具體的範圍？也許您可以提供額外的資訊來重現錯誤，或者您可以消除不需要演示問題的不必要步驟。
如果你發現一個沒有測試的錯誤報告，貢獻一個失敗的測試是非常有用的。這也是探索原始碼的好方法：檢視現有的測試檔案將教您如何編寫更多測試。新測試最好以補丁的形式貢獻，如稍後在“貢獻 Rails 程式碼”部分所述。
您可以做的任何事情使錯誤報告更簡潔或更容易重現，這有助於人們嘗試編寫程式碼來修復這些錯誤——無論您最終是否自己編寫程式碼。
2.2 測試補丁
您還可以透過檢查已透過 GitHub 在 Rails 上提交到 Ruby 的拉取請求來提供幫助。為了應用某人的更改，首先建立一個專用分支：
$ 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 問題上發表評論以表示您的批准。你的評論應該表明你喜歡這個變化以及你喜歡它的什麼。就像是：
我喜歡你在 generate_finder_sql 中重構程式碼的方式 - 好多了。測試看起來也不錯。
如果您的評論只是“+1”，那麼其他 reviewers 可能不會太認真對待它。表明您花時間重新 view 拉取請求。
3 為 Rails 文件做貢獻
Rails 上的 Ruby 有兩套主要文件：指南，可以幫助您 在Rails上了解Ruby，以及API，作為參考。
您可以幫助改進 Rails 指南或 API 參考，方法是使它們更加連貫、一致或可讀，新增缺失的資訊，更正事實錯誤，修復拼寫錯誤，或使用最新的 Rails 更新它們。
為此，請更改 Rails 指南原始檔（位於 [此處] GitHub 上的 (https://github.com/rails/rails/tree/main/guides/source)）或原始碼中的 RDoc 註釋。然後開啟拉取請求以將您的更改應用到主分支。
在處理文件時，請考慮 API 文件指南 和 Ruby on Rails 指南指南。
4 翻譯Rails指南
我們很高興有人自願翻譯 Rails 指南。只需按照以下步驟操作：
- 分叉 https://github.com/rails/rails。
- 為您的語言新增原始檔夾，例如：guides/source/it-IT 用於義大利語。
- 將guides/source 的內容複製到您的語言目錄中並進行翻譯。
- 不要翻譯 HTML 檔案，因為它們是自動產生的。
請注意，翻譯不會提交到 Rails 儲存庫；如上所述，您的工作生活在您的叉子中。這是因為，在實踐中，透過補丁進行的文件維護僅適用於英語。
要產生 HTML 格式的指南，您需要將指南依賴項 cd 安裝到 guides 目錄中，然後執行（例如，for it-IT）：
# 只安裝指南所需的 gems。要撤消執行： bundle config --delete without
$ bundle install --without job cable storage ujs test db
$ cd guides/
$ bundle exec rake guides:generate:html GUIDES_LANGUAGE=it-IT
這將在 output 目錄中產生指南。
Redcarpet Gem 不適用於 JRuby。
我們瞭解的翻譯工作（各種版本）：
- 義大利語：https://github.com/rixlabs/docrails
- 西班牙語：https://github.com/latinadeveloper/railsguides.es
- 波蘭語：https://github.com/apollo/docrails
- 法語：https://github.com/railsfrance/docrails
- 捷克：https://github.com/rubyonrails-cz/docrails/tree/czech
- 土耳其語：https://github.com/ujk/docrails
- 韓文：https://github.com/rorlakr/rails-guides
- 簡體中文：https://github.com/ruby-china/guides
- 繁體中文：https://github.com/docrails-tw/guides
- 俄語：https://github.com/morsbox/rusrails
- 日語：https://github.com/yasslab/railsguides.jp
- 巴西葡萄牙語：https://github.com/campuscode/rails-guides-pt-BR
5 為 Rails 程式碼做貢獻
5.1 搭建開發環境
要從提交錯誤到幫助解決現有問題或將您自己的程式碼貢獻給 Rails 上的 Ruby，您必須能夠執行其測試套件。在指南的這一部分中，您將瞭解如何在計算機上設定測試。
5.1.1 簡單的方法
讓開發環境準備好進行駭客攻擊的最簡單和推薦的方法是使用 rails-dev-box。
5.1.2 艱難之路
如果您無法使用 Rails 開發框，請參閱 其他指南。
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
5.4 在本地分支上執行應用程式
如果您需要一個虛擬的 Rails 應用程式來測試更改，則 rails new 的 --dev 標誌會產生一個使用您本地分支的應用程式：
$ cd rails
$ bundle exec rails new ~/my-test-app --dev
在 ~/my-test-app 中產生的應用程式針對您的本地分支執行
尤其是在伺服器重新啟動時可以看到任何修改。
5.5 編寫程式碼
現在開始忙碌並新增/編輯程式碼。你現在在你的分支上，所以你可以寫任何你想要的東西（確保你在正確的分支上使用 git branch -a）。但是，如果您打算將更改提交回來以包含在 Rails 中，請記住以下幾點：
- 獲取正確的程式碼。
- 使用 Rails 習語和 helpers。
- 包括在沒有程式碼的情況下失敗的測試，並透過它。
- 更新（周圍）文件、其他地方的示例和指南：受您貢獻影響的任何內容。
提示：外觀上的更改不會對 Rails 的穩定性、功能性或可測試性增加任何實質性的內容，通常不會被接受（閱讀更多有關 我們做出此決定的理由 的資訊）。
5.5.1 遵循編碼約定
Rails 遵循一組簡單的編碼風格約定：
- 兩個空格，沒有製表符（用於縮排）。
- 沒有 trailing 空格。空行不應有任何空格。
- 私有/受保護後縮排且無空行。
- 對雜湊使用 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：
$ rubocop actionpack/lib/action_controller/metal/strong_parameters.rb
Inspecting 1 file
.
1 file inspected, no offenses detected
對於 rails-ujs CoffeeScript 和 JavaScript 檔案，您可以在 actionview 資料夾中執行 npm run lint。
5.5.2 拼寫檢查
我們正在執行 misspell 主要是寫在
Golang 使用 GitHub Actions 檢查拼寫。正確的
使用 misspell 快速拼錯英語單詞。 misspell 與大多數其他拼寫檢查器不同
因為它不使用自定義字典。您可以使用以下命令對所有檔案在本地執行 misspell：
find . -type f | xargs ./misspell -i 'aircrafts,devels,invertions' -error
值得注意的 misspell 幫助選項或標誌是：
-
-i字串：忽略以下更正，逗號分隔 -
-w：用更正覆蓋檔案（預設只是顯示）
我們還使用 GitHub Actions 執行 codespell 來檢查拼寫和
codespell 執行在小型自定義詞典 上。
codespell 是用 Python 編寫的，您可以使用以下命令執行它：
codespell --ignore-words=codespell.txt
5.6 對您的程式碼進行基準測試
對於可能對效能產生影響的更改，請對您的 編碼並衡量影響。請分享您使用的基準指令碼 作為結果。您應該考慮在提交中包含此資訊 訊息，以允許未來的貢獻者輕鬆驗證您的發現和 確定它們是否仍然相關。 （例如，未來的最佳化 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 actionmailer
$ SEED=15002 bin/test
執行單個測試檔案：
$ cd actionmailer
$ SEED=15002 bin/test test/mail_layout_test.rb
5.7.7 序列執行測試
Action Pack 和 Action View 單元測試預設並行執行。如果您遇到隨機
測試失敗，您可以設定隨機化種子並透過設定 PARALLEL_WORKERS=1 讓這些單元測試序列執行
$ cd actionview
$ PARALLEL_WORKERS=1 SEED=53708 bin/test test/template/test_case_test.rb
5.7.8 測試 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:postgresql
最後，
$ bundle exec rake test
現在將依次執行他們三個。
您還可以單獨執行任何單個測試：
$ ARCONN=sqlite3 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.8 警告
測試套件在啟用警告的情況下執行。理想情況下，Rails 上的 Ruby 不應發出警告，但可能會有一些警告，以及來自第三方庫的一些警告。請忽略（或修復！）它們，如果有的話，並提交不會發出新警告的補丁。
5.9 更新文件
Rails 指南 上的 Ruby 提供了 Rails 功能的高級別 view，而 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 忽略編輯器/IDE 建立的檔案
一些編輯器和 IDE 會在 rails 資料夾中建立隱藏檔案或資料夾。與其手動從每次提交中排除那些或將它們新增到 Rails' .gitignore，您應該將它們新增到您自己的 global gitignore 檔案。
5.12 更新 Gemfile.lock
某些更改需要依賴項升級。在這些情況下，請確保執行 bundle update 以獲取正確版本的依賴項並在更改中提交 Gemfile.lock 檔案。
5.13 提交您的更改
當您對計算機上的程式碼感到滿意時，您需要將更改提交到 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
小費。請在適當的時候將您的提交壓縮為單個提交。這 簡化未來的櫻桃選擇並保持 git 日誌乾淨。
5.14 更新你的分支
很可能在您工作時對 main 進行了其他更改。去拿他們：
$ git checkout main
$ git pull --rebase
現在根據最新更改重新應用您的補丁：
$ git checkout my_new_branch
$ git rebase main
沒有衝突？測試還透過嗎？你覺得改變還是合理的？然後繼續前進。
5.15 前叉
導航到 Rails GitHub 儲存庫，然後按右上角的“Fork”。
將新的遠端新增到本地機器上的本地儲存庫：
$ 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.16 發出拉取請求
導航到您剛剛推送到的 Rails 儲存庫（例如 https://github.com/your-user-name/rails）並點擊上方欄中的“拉取請求”（程式碼正上方）。 在下一頁，單擊右上角的“新建拉取請求”。
拉取請求應針對基礎儲存庫 rails/rails 和分支 main。
頭儲存庫將是您的工作（your-user-name/rails），而分支將是
無論你給你的分支起什麼名字。準備好後，單擊“建立拉取請求”。
確保包含您引入的變更集。填寫一些關於 您的潛在補丁，使用提供的拉取請求模板。完成後點選“建立 pull request”。Rails 核心團隊將收到您提交的通知。
5.17 得到一些反饋
大多數拉取請求在合併之前會經過幾次迭代。 不同的貢獻者有時會有不同的意見，而且往往 補丁在合併之前需要修改。
Rails 的一些貢獻者打開了來自 GitHub 的電子郵件通知，但是 其他人沒有。此外，（幾乎）每個在 Rails 上工作的人都是一個 志願者，因此您可能需要幾天時間才能獲得關於 拉取請求。不要絕望！有時它很快；有時它很慢。這樣的 是開源的生活。
如果已經一個多星期了，你還沒有聽到任何訊息，你可能想試試 並推動事情。您可以使用 rubyonrails-core 郵件 列表 用於此。你也可以 在拉取請求上留下另一個評論。
在等待對拉取請求的反饋時，開啟其他一些 拉請求並給其他人一些！他們會很感激的 就像您欣賞補丁的反饋一樣。
請注意，您的拉取請求可能會被其他人標記為“已批准” 有權合併它。在成員之前可能仍需要進一步的更改 核心或提交者團隊接受它。為防止混淆，在給予時 對他人拉取請求的反饋，請避免將其標記為“已批准”。
5.18 根據需要迭代
您獲得的反饋完全有可能提出更改建議。不要氣餒：為活躍的開源專案做出貢獻的全部意義在於利用社群的知識。如果人們鼓勵您調整程式碼，那麼進行調整並重新提交是值得的。如果反饋是您的程式碼不屬於核心，您可能仍會考慮將其作為 gem 釋出。
5.18.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.18.2 更新拉取請求
有時您會被要求對您擁有的程式碼進行一些更改 已經承諾。這可以包括修改現有的提交。在這 案例 Git 不允許您將更改作為推送分支推送 和當地分行不匹配。而不是開啟一個新的拉取請求， 您可以按照前面所述在 GitHub 上強制推送到您的分支 壓縮提交部分：
$ git push fork my_new_branch --force-with-lease
這將使用您的新程式碼更新 GitHub 上的分支和拉取請求。
透過使用 --force-with-lease 強制推送，git 將更安全地更新
遠端比典型的 -f，可以從遠端刪除工作
你還沒有的。
5.19 Rails 上 Ruby 的舊版本
如果您想在 Rails 上為舊版本的 Ruby 新增修復程式，則需要設定並切換到您自己的本地 tracking 分支。這是切換到 4-0-stable 分支的示例：
$ git branch --track 4-0-stable rails/4-0-stable
$ git checkout 4-0-stable
提示：你可能想將你的 Git 分支名稱放在你的 shell 提示中 以便更容易記住您正在使用的程式碼版本。
在處理舊版本之前，請檢查維護策略。
5.19.1 向後移植
合併到 main 中的更改的目標在於用於 Rails 的下一個主要版本。有時，將更改傳播回較舊的穩定分支以包含在維護版本中可能是有益的。通常，安全修復和錯誤修復是向後移植的良好候選者，而改變預期行為的新功能和補丁將不被接受。如有疑問，最好在向後移植更改之前諮詢 Rails 團隊成員，以避免浪費精力。
對於簡單的修復，向後移植更改的最簡單方法是從 main 中的更改中提取差異並將它們應用到目標分支。
首先，確保您的更改是當前分支和主分支之間的唯一差別：
$ git log main..HEAD
然後提取差異：
$ git format-patch main --stdout > ~/my_changes.patch
切換到目標分支並應用您的更改：
$ git checkout -b my_backport_branch 4-2-stable
$ git apply ~/my_changes.patch
這適用於簡單的更改。但是，如果您的更改很複雜，或者如果 main 中的程式碼與您的目標分支明顯偏離，則可能需要您做更多的工作。向後移植的難度因情況而異，有時根本不值得付出努力。
一旦你解決了所有衝突並確保所有測試都透過，推送你的更改併為你的反向移植開啟一個單獨的拉取請求。還值得注意的是，較舊的分支可能具有與 main 不同的一組構建目標。如果可能，最好在提交拉取請求之前，首先針對目標分支的 rails.gemspec 允許的最舊 Ruby 版本在本地測試您的向後移植。
然後……想想你的下一個貢獻！
6 Rails 貢獻者
所有貢獻都在 Rails Contributors 中獲得積分。
回饋
我們鼓勵您幫助提高本指南的品質。
如果您發現任何拼寫錯誤或資訊錯誤，請提供回饋。 要開始回饋，您可以閱讀我們的 回饋 部分。
您還可能會發現不完整的內容或不是最新的內容。 請務必為 main 新增任何遺漏的文件。假設是 非穩定版指南(edge guides) 請先驗證問題是否已經在主分支上解決。 請前往 Ruby on Rails 指南寫作準則 查看寫作風格和慣例。
如果由於某種原因您發現要修復的內容但無法自行修補，請您 提出 issue。
關於 Ruby on Rails 的任何類型的討論歡迎提供任何文件至 rubyonrails-docs 討論區。