Chapters1 問題の報告
Ruby on Railsでは、問題（主にバグや新しいコードの貢献）を追跡するためにGitHub Issue Trackingを使用しています。Ruby on Railsのバグを見つけた場合は、まずここから始める必要があります。問題を報告したり、問題にコメントしたり、プルリクエストを作成するには、(無料の)GitHubアカウントを作成する必要があります。
注意：最新リリースバージョンのRuby on Railsのバグは、最も注目される可能性があります。また、Railsコアチームは常に、時間をかけてedge Rails（現在開発中のRailsのコード）をテストできる人々からのフィードバックに興味を持っています。このガイドの後半で、テスト用のedge Railsを取得する方法について説明します。サポートされているバージョンに関する情報については、メンテナンスポリシーを参照してください。セキュリティの問題は、GitHubの問題追跡システムで報告しないでください。
1.1 バグレポートの作成
セキュリティリスクではないRuby on Railsの問題を見つけた場合は、まずGitHubのIssuesで報告されていないか検索してください。報告されていない場合は、次のステップとして新しい問題を作成します（セキュリティの問題については、次のセクションを参照してください）。
問題がフレームワークにバグがあるかどうかを判断するために必要なすべての情報を含めるために、問題のテンプレートを用意しました。各問題には、タイトルと問題の明確な説明が必要です。期待される動作を示すコードサンプルや失敗するテストなど、関連する情報をできるだけ多く含めるようにしてください。また、システムの構成も含めてください。バグを再現し、修正方法を見つけるために、自分自身や他の人が問題を再現しやすくすることが目標です。
問題を報告すると、すぐにアクティビティが表示されるわけではありません。ただし、「コードレッド、ミッションクリティカル、世界が終わりに近づいている」というような重大なバグでない限り、すぐにアクティビティが表示されるわけではありません。これは、私たちがあなたのバグに関心を持っていないという意味ではありません。ただ、多くの問題とプルリクエストがあるためです。同じ問題を抱えている他の人があなたの問題を見つけ、バグを確認し、修正に協力することがあります。バグを修正する方法を知っている場合は、プルリクエストを作成してください。
1.2 実行可能なテストケースの作成
問題を再現する方法を提供することで、他の人が問題を確認し、調査し、最終的に修正するのに役立ちます。これは、実行可能なテストケースを提供することで行うことができます。このプロセスを簡単にするために、いくつかのバグレポートのテンプレートを準備しました。これらのテンプレートは、リリースされたバージョンのRails (*_gem.rb) またはedge Rails (*_main.rb) のいずれかに対してテストケースを設定するためのボイラープレートコードが含まれています。
- Active Record（モデル、データベース）の問題のテンプレート：gem / main
- Active Record（マイグレーション）の問題のテストのテンプレート：gem / main
- Action Pack（コントローラ、ルーティング）の問題のテンプレート：gem / main
- Active Jobの問題のテンプレート：gem / main
- Active Storageの問題のテンプレート：gem / main
- Action Mailboxの問題のテンプレート：gem / main
- その他の問題の汎用テンプレート：gem / main
これらのテンプレートには、リリースされたバージョンのRails (*_gem.rb) またはedge Rails (*_main.rb) のいずれかに対してテストケースを設定するためのボイラープレートコードが含まれています。
適切なテンプレートの内容を.rbファイルにコピーし、必要な変更を行って問題を示してください。ターミナルでruby the_file.rbを実行することで、テストケースが失敗するはずです。
その後、実行可能なテストケースをgistに共有するか、内容を問題の説明に貼り付けることができます。
1.3 セキュリティの問題に対する特別な取り扱い
警告: セキュリティの脆弱性に関しては、公開されたGitHubの問題報告で報告しないでください。Railsセキュリティポリシーページには、セキュリティの問題に関する手順が詳細に記載されています。
1.4 機能リクエストについてはどうですか？
GitHubの問題に「機能リクエスト」の項目を入れないでください。Ruby on Railsに追加される新しい機能を要求する場合は、自分でコードを書くか、他の誰かにコードの作成を依頼する必要があります。このガイドの後半では、Ruby on Railsへのパッチの提案方法について詳細な手順が説明されています。コードのないウィッシュリストの項目をGitHubの問題に入力すると、レビューされるとすぐに「無効」とマークされることが予想されます。
時には、「バグ」と「機能」の間の境界線は曖昧なものです。一般的に、機能は新しい動作を追加するものであり、バグは正しくない動作を引き起こすものです。時には、コアチームが判断を下す必要があります。ただし、この区別は通常、変更がリリースされるパッチを決定するものです。私たちは機能の提出を歓迎します！ただし、メンテナンスブランチにはバックポートされません。
パッチを作成する前に、アイデアのフィードバックを受ける場合は、rails-coreディスカッションボードでディスカッションを開始してください。誰も関心を持っていない場合は、返信がないかもしれません。その機能を構築することに興味を持っている他の人を見つけるかもしれません。受け入れられないという意見を得るかもしれません。しかし、新しいアイデアを議論するのに適切な場所です。GitHubの問題は、新しい機能に必要な長くて複雑な議論にはあまり適していません。
2 既存の問題の解決に協力する
問題を報告するだけでなく、コアチームが既存の問題を解決するのを助けるためにフィードバックを提供することもできます。Railsコア開発に初めて参加する場合、フィードバックを提供することでコードベースとプロセスに慣れるのに役立ちます。
GitHubの問題リストをチェックすると、すでに対応が必要な問題がたくさんあります。これらについてどのように対処できますか？実際にはかなりのことができます。
2.1 バグレポートの検証
まずは、バグレポートを検証するだけでも役立ちます。報告された問題を自分のコンピュータで再現できますか？もしそうなら、同じことを見ているというコメントを問題に追加することができます。
問題が非常に曖昧な場合、より具体的なものに絞り込むのに役立ちますか？バグを再現するための追加情報を提供したり、問題を示すために必要のない手順を削除したりすることができるかもしれません。
テストがないバグレポートを見つけた場合、失敗するテストを提供すると非常に役立ちます。これはソースコードを調査するための素晴らしい方法でもあります。既存のテストファイルを見ることで、より多くのテストを書く方法を学ぶことができます。新しいテストは、後述する「Railsコードへの貢献」セクションで説明されているように、パッチの形で提供するのが最適です。
バグレポートをより簡潔かつ再現しやすくするためにできることは何でも、それらのバグを修正するためのコードを書こうとしている人々に役立ちます。自分自身でコードを書くかどうかに関係なく。 * 変更は実際に機能していますか？ * テストは満足していますか？テストが何をテストしているのか理解できますか？不足しているテストはありますか？ * 適切なドキュメンテーションのカバレッジがありますか？他の場所のドキュメントを更新する必要がありますか？ * 実装は好きですか？変更の一部をより良いまたは高速な方法で実装できますか？
プルリクエストが良い変更を含んでいると満足したら、GitHubの問題にコメントして調査結果を示してください。コメントには、変更が好きであり、その点について何が好きかを示す必要があります。以下のような内容です。
generate_finder_sqlのコードの再構築方法が気に入りました。テストも良さそうです。
コメントが単に「+1」という場合、他のレビュワーはそれをあまり真剣に受け取らない可能性があります。レビューに時間をかけたことを示してください。
3 Railsドキュメントへの貢献
Ruby on Railsには、Ruby on Railsの学習を支援するガイドと、リファレンスとして機能するAPIの2つの主要なドキュメントセットがあります。
RailsガイドまたはAPIリファレンスをより一貫性のある、一貫性のある、読みやすいものにしたり、欠落している情報を追加したり、事実の誤りを修正したり、タイポを修正したり、最新のエッジRailsに合わせて更新したりすることで、RailsガイドまたはAPIリファレンスを改善することができます。
そのためには、Railsガイドのソースファイル（GitHubのこちらにあります）またはソースコードのRDocコメントを変更します。その後、変更をメインブランチに適用するためにプルリクエストを開きます。
ドキュメント作業を行う際には、APIドキュメントガイドラインとRuby on Railsガイドラインを考慮してください。
4 Railsガイドの翻訳
Railsガイドの翻訳に協力していただけると嬉しいです。以下の手順に従ってください。
- https://github.com/rails/rails をフォークします。
- 言語ごとのソースフォルダを追加します。例えば、イタリア語の場合はguides/source/it-ITとします。
- guides/sourceの内容を言語ディレクトリにコピーして翻訳します。
- HTMLファイルは翻訳しないでください。これらは自動的に生成されます。
翻訳はRailsリポジトリに提出されません。作業は上記のようにフォーク内で行われます。これは、実際にはドキュメントのメンテナンスは英語でのみ持続可能であるためです。
HTML形式のガイドを生成するには、ガイドの依存関係をインストールする必要があります。guidesディレクトリに移動し、次のコマンドを実行します（例：it-ITの場合）。
# ガイドに必要なジェムのみをインストールします。元に戻すには、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/apohllo/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 開発環境のセットアップ
バグの報告から既存の問題の解決や独自のコードの貢献に移るためには、Ruby on Railsのテストスイートを実行できる必要があります。このガイドのこのセクションでは、コンピュータ上でテストをセットアップする方法について学びます。
5.1.1 GitHub Codespacesを使用する
Codespacesが有効な組織のメンバーであれば、Railsをその組織にフォークし、GitHub上でCodespacesを使用することができます。Codespaceは必要なすべての依存関係で初期化され、すべてのテストを実行できます。
5.1.2 VS Code Remote Containersを使用する
Visual Studio CodeとDockerがインストールされている場合、VS Code remote containersプラグインを使用できます。このプラグインは、リポジトリの.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を使用できない場合は、ローカル開発の設定方法についてはこの別のガイドを参照してください。これは、依存関係のインストールがOSに依存するため、難しい方法とされています。
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のイディオムとヘルパーを使用すること。
- コードがないと失敗し、コードがあると成功するテストを含めること。
- 貢献に影響を受けるドキュメント、他の場所の例、ガイドを更新すること。
- 変更が機能を追加、削除、または変更する場合は、CHANGELOGエントリを含めること。バグ修正の場合は、CHANGELOGエントリは必要ありません。
Railsの安定性、機能、テスト可能性に実質的な追加を行わない見た目の変更は、一般的には受け入れられません（この決定の背後にある理由については、こちらを参照してください）。
5.5.1 コーディング規約に従う
Railsは、シンプルなコーディングスタイルの規約に従います。
- インデントには2つのスペースを使用し、タブは使用しません。
- 末尾の空白はありません。空白を含む空行はありません。
- private/protectedの後にはインデントと空行はありません。
- ハッシュにはRuby >= 1.9の構文を使用します。
{ a: :b }を{ :a => :b }よりも好みます。 and/orよりも&&/||を好みます。- クラスメソッドには
self.methodではなくclass << selfを使用します。 my_method( my_arg )やmy_method my_argではなく、my_method(my_arg)を使用します。a=bではなくa = bを使用します。refuteの代わりにassert_notメソッドを使用します。- 1行のブロックでは、
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
rails-ujsのCoffeeScriptとJavaScriptファイルに対しては、actionviewフォルダでnpm run lintを実行できます。
5.5.2 スペルチェック
私たちは、スペルチェックのためにGolangで主に書かれたmisspellを実行しています。GitHub Actionsでスペルチェックを行います。misspellは、カスタム辞書を使用しないため、他のほとんどのスペルチェッカーとは異なります。すべてのファイルに対してローカルでmisspellを実行できます。
$ find . -type f | xargs ./misspell -i 'aircrafts,devels,invertions' -error
注目すべきmisspellのヘルプオプションまたはフラグは次のとおりです。
-istring: 以下の修正を無視します。カンマで区切ります。-w: 修正でファイルを上書きします（デフォルトは表示のみです）。
私たちはまた、スペルチェックのためにPythonで書かれたcodespellをGitHub Actionsで実行しています。codespellは、小さなカスタム辞書に対して実行されます。codespellは次のように実行できます。
$ codespell --ignore-words=codespell.txt
5.6 コードのベンチマーク
パフォーマンスに影響を与える可能性のある変更については、コードのベンチマークを行い、影響を測定してください。使用したベンチマークスクリプトと結果を共有してください。これにより、将来の貢献者が簡単に結果を確認し、それがまだ有効かどうかを判断できるように、コミットメッセージにこの情報を含めることを検討してください（たとえば、Ruby VMの将来の最適化によって、特定の最適化が不要になる場合があります）。 特定のシナリオに最適化する際には、他の一般的なケースのパフォーマンスが低下する可能性があります。 そのため、実際のプロダクションアプリケーションから抽出した代表的なシナリオのリストに対して変更をテストすることが重要です。
ベンチマークテンプレートを使用すると、ベンチマークを設定するためのボイラープレートコードが含まれています。このテンプレートは、スクリプトにインラインで組み込むことができる比較的独立した変更をテストするために設計されています。
5.7 テストの実行
Railsでは、変更をプッシュする前に完全なテストスイートを実行することは一般的ではありません。特にrailtiesのテストスイートは時間がかかりますし、rails-dev-boxを使用した推奨されるワークフローでは、ソースコードが/vagrantにマウントされるため、特に時間がかかります。
そのため、コードに明らかに影響を与えるテストを実行し、変更が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 actionmailer
$ SEED=15002 bin/test
単一のテストファイルを実行する場合:
$ cd actionmailer
$ SEED=15002 bin/test test/mail_layout_test.rb
5.7.8 直列でテストの実行
デフォルトでは、Action PackとAction Viewのユニットテストは並列で実行されます。ランダムなテストの失敗が発生している場合、ランダム化シードを設定し、これらのユニットテストを直列で実行するためにPARALLEL_WORKERS=1を設定することができます。
$ cd actionview
$ PARALLEL_WORKERS=1 SEED=53708 bin/test test/template/test_case_test.rb
5.7.9 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.10 テストでデバッガを使用する
外部のデバッガ（pry、byebugなど）を使用するには、デバッガをインストールし、通常どおり使用します。デバッガの問題が発生した場合は、PARALLEL_WORKERS=1を設定してテストを直列で実行するか、-n test_long_test_nameを使用して単一のテストを実行します。
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は、各リリースの変更内容を記録する重要な部分です。
もし新しい機能を追加したり、機能の削除、非推奨通知の追加を行った場合は、変更したフレームワークのCHANGELOGの一番上にエントリを追加してください。リファクタリング、マイナーバグ修正、ドキュメントの変更などは通常CHANGELOGには含めません。
CHANGELOGのエントリは、変更内容を要約し、最後に著者の名前を記述する必要があります。必要に応じて複数行を使用することができ、4つのスペースでインデントされたコード例を添付することもできます。変更が特定の問題に関連している場合は、問題番号を添付する必要があります。以下にCHANGELOGエントリの例を示します。
* 変更内容を簡潔に説明する変更の要約。複数行を使用し、80文字程度で折り返すことができます。必要に応じてコード例も使用できます:
class Foo
def bar
puts 'baz'
end
end
コード例の後に続けることができ、問題番号を添付することもできます。
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
# 既存の挙動
end
5.11.2 挙動の変更
互換性のない変更が既存の挙動を変更する場合、フレームワークのデフォルトを追加する必要があります。フレームワークのデフォルトは、アプリケーションが新しいデフォルトに一つずつ切り替えることで、Railsのアップグレードを容易にします。
新しいフレームワークのデフォルトを実装するには、まず対象のフレームワークにアクセサを追加して設定を作成します。デフォルト値を既存の挙動に設定することで、アップグレード中に何も壊れないようにします。
module ActiveJob
mattr_accessor :existing_behavior, default: true
end
新しい設定により、条件に応じて新しい挙動を実装することができます。
def changed_method
if ActiveJob.existing_behavior
# 既存の挙動
else
# 新しい挙動
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_7_1.rb.tt
# Rails.application.config.active_job.existing_behavior = false
最後のステップとして、configuration.mdの設定ガイドに新しい設定を追加します。
#### `config.active_job.existing_behavior`
| バージョン | デフォルト値 |
| ---------- | ------------ |
| (元の値) | `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
これにより、コミットメッセージを書くためにエディタが起動します。終了したら、保存して閉じて続行します。
整形された説明的なコミットメッセージは、他の人が変更がなぜ行われたのかを理解するのに非常に役立ちますので、書くために時間をかけてください。
良いコミットメッセージは以下のようになります。
短い要約（理想的には50文字以下）
必要に応じて、より詳細な説明を記述します。各行は72文字で折り返します。
できるだけ説明的にしてください。コミットの内容が明らかだと思っていても、
他の人には明らかではないかもしれません。関連する問題に既に存在する
説明を追加してください。履歴を確認するためにウェブページを訪れる必要はありません。
説明セクションには複数の段落を含めることができます。
コードの例は、4つのスペースでインデントすることで埋め込むことができます。
class ArticlesController
def index
render json: Article.limit(10)
end
end
また、箇条書きも追加できます。
- ダッシュ（-）またはアスタリスク（*）で行を始めることで、箇条書きを作成します。
- 72文字で行を折り返し、可読性のために追加の行は2つのスペースでインデントします。
適切な場合は、コミットを1つにまとめてください。これにより、将来のチェリーピックが簡素化され、gitのログがきれいに保たれます。
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リポジトリに移動し、右上隅の「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.17 プルリクエストを作成する
作成したRailsリポジトリ（例：https://github.com/your-user-name/rails）に移動し、コードの上にある「Pull Requests」をクリックします。 次のページで、右上隅にある「New pull request」をクリックします。
プルリクエストは、ベースリポジトリがrails/railsであり、ブランチがmainである必要があります。
ヘッドリポジトリはあなたの作業（your-user-name/rails）であり、ブランチは
作成したブランチの名前です。準備ができたら、「create pull request」をクリックします。
導入した変更セットが含まれていることを確認してください。プルリクエストテンプレートを使用して、パッチに関する詳細を入力します。完了したら、「Create pull request」をクリックします。
5.18 フィードバックを受け取る
ほとんどのプルリクエストは、マージされる前に数回の反復を経ることになります。 異なる貢献者によって異なる意見があることがあり、 パッチを修正する必要があることがよくあります。
Railsのいくつかの貢献者は、GitHubからのメール通知をオンにしていますが、 他の人はしていません。さらに、Railsで作業する（ほぼ）すべての人は ボランティアですので、プルリクエストに最初のフィードバックを得るまでには数日かかる場合があります。諦めないでください！時には速く、時には遅くなります。それがオープンソースの生活です。
1週間以上経っても何も聞こえてこない場合は、事態を進展させるために試みることができます。 これには、rubyonrails-coreディスカッションボードを使用できます。また、プルリクエストに別のコメントを残すこともできます。 フィードバックを待っている間に、他のいくつかのプルリクエストを開いて、他の人にフィードバックを提供しましょう！あなたがパッチのフィードバックを評価するのと同じように、他の人もそれを感謝するでしょう。
ただし、コードの変更をマージする権限は、CoreチームとCommittersチームにのみ与えられています。 誰かがフィードバックをしてあなたの変更を「承認」した場合、彼らにはマージする能力や最終的な判断権がないかもしれません。
5.19 必要に応じて反復する
フィードバックを受け取った場合、変更が提案される可能性があります。落胆しないでください：活発なオープンソースプロジェクトへの貢献の目的は、コミュニティの知識を活用することです。人々があなたのコードを微調整するように勧めるなら、それは微調整して再提出する価値があります。もしフィードバックがあなたのコードがマージされないというものであれば、それをジェムとしてリリースすることを考える価値があります。
5.19.1 コミットの統合
私たちがお願いすることの一つは、「コミットを統合する」ということです。これにより、すべてのコミットが1つのコミットに統合されます。私たちは、1つのコミットであるプルリクエストを好みます。これにより、安定したブランチへの変更のバックポートが容易になり、悪いコミットを元に戻すことが容易になり、gitの履歴を追いやすくなります。Railsは大規模なプロジェクトであり、不要なコミットが多くのノイズを生む可能性があります。
$ git fetch rails
$ git checkout my_new_branch
$ git rebase -i rails/main
< 最初のコミット以外のすべてのコミットについて 'squash' を選択します。 >
< コミットメッセージを編集して意味を持たせ、すべての変更を説明します。 >
$ 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を使用して強制プッシュすることで、typicalな-fよりもgitはリモートをより安全に更新します。これにより、既に持っていないリモートの作業を削除することができます。
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 Contributorsでクレジットを受けます。
フィードバック
このガイドの品質向上にご協力ください。
タイポや事実の誤りを見つけた場合は、ぜひ貢献してください。 開始するには、ドキュメントへの貢献セクションを読んでください。
不完全なコンテンツや最新でない情報も見つかるかもしれません。 メインのドキュメントに不足しているドキュメントを追加してください。 修正済みかどうかは、まずEdge Guidesを確認してください。 スタイルと規約については、Ruby on Rails Guides Guidelinesを確認してください。
修正すべき点を見つけたが、自分で修正できない場合は、 問題を報告してください。
そして最後に、Ruby on Railsのドキュメントに関するあらゆる議論は、公式のRuby on Railsフォーラムで大歓迎です。