Railsへのコントリビューションについて調べてみた

Railsへのコントリビューションに関する次のドキュメントを読んでみました。

(英語) Contributing to Ruby on Rails — Ruby on Rails Guides
(日本語) Ruby on Rails に貢献する方法 | Rails ガイド

この中で特に参考になった部分を中心に書いていきます。

😼 コントリビューションの基礎

Ruby on Railsのバグを見付け足ら「Issues · rails/rails - GitHub」で既存のものがないか探して、な、ればPOST
最新版(edge)はバグがある可能性があるし、バグが有った場合に取り込まれやすいのでコントリビュートのチャンスが多い。コントリビュートのチャンスが多い

🎂 セキュリティの問題が見つかった場合

GitHub ISSUEにあげてはダメ(悪用される可能性があるから)
「Ruby on Rails: Security policy」あたりにセキュリティのISSUEの立て方が書かれています。

😀 バグなどのISSUE

ISSUEには再現可能なサンプルコードをつけよう
実行可能なテストケースをちゃんと作ろう。テストケースのテンプレートを活用しよう => 1.2 Create an Executable Test Case - Ruby on Rails Guide Contributing to Ruby on Railss
テストケースは、gistなどに貼って使おう
バグの調査に役立つ情報があれば、ISSUEに書き込もう
failするテストはコントリビュートのチャンスだ

テストバッチ

forkしてテストパッチを作ろう
- 変更が確実に動作しているかを確認しよう
- テストによってより良くなっているか？変更点のテストがきちんと存在しているか？
- ドキュメントが適切にアップデートされているか？
- 変更点はコードとして適切で、高速に動作するか？

🐰 Gistのテンプレート

ActiveRecord や ActionController のgistテンプレートのです。バグをレポートするときに使います。

🐡 機能追加のリクエストについて

必ず動作するパッチを作ってGitHubにISSUEを作ろう(動作するパッチがない場合はinvalidになる)
機能追加はほかの機能に影響を与える可能性があるのでコアチームによって判断される
アイデアを相談したいときは「rails-core mailing list」に投げてみよう

健全性のチェック

もしRails開発者の知り合いがいるなら、あらかじめ修正したコードをみせることで、
適切なコードか否かをちゃんとチェックしよう。

Feedbackを受けよう

Merge Requestを出したら、いくつかのフィードバックや意見が来るので対応しよう。
マイナーチェンジは悪いことじゃないのでポジティブに意見を受け入れよう。
あまりにもMerge Requestに反応がないようなら、メーリングリストにPostしてみよう。

🍄 コードを書くときの注意点

バグフィックスや機能追加でコードを書く際には次の点に注意しよう。

- 正しいコードを書こう
- Railsのイデオム/Helperを適切に書こう
- テストが通過しない場合は、テストが通過するように修正しよう
- 変更点に関するドキュメントもアップデートをお忘れなく

🍣 Railsのcoding style

- 2スペースを使う。タブは使わない
- 不要なスペースをつけないようにしよう
- private/protectedの後はindentをつけよう
- 1.9以降のhashシンタックス { a: b } を使おう
- `&&` や `||` を使おう
- `class << self` を使おう
- `MyClass.my_method(my_arg)` が望ましい
- `a = b` としよう
- `assert_not` を使おう
- `{ do_stuff }` としよう

🚕 パフォーマンスに影響する変更

gem「benchmark-ips 等を利用してベンチマークを取ること。

require 'benchmark/ips'
 
Benchmark.ips do |x|
  x.report('addition') { 1 + 2 }
  x.report('addition with send') { 1.send(:+, 2) }
end

Calculating -------------------------------------
            addition   132.013k i/100ms
  addition with send   125.413k i/100ms
-------------------------------------------------
            addition      9.677M (± 1.7%) i/s -     48.449M
  addition with send      6.794M (± 1.1%) i/s -     33.987M

🏈 テストの実行

テストの実行方法は次のとおり。

# Rails 全体のテスト
$ cd rails
$ bundle exec rake test

# ActionMailerに関するテスト
$ cd actionmailer
$ bundle exec rake test

# ActiveRecordに関するテスト DBの種類ごとのテストも可能
$ cd activerecord
$ bundle exec rake test:sqlite3
$ bundle exec rake test:mysql2
$ bundle exec rake test:postgresql

🐞 ドキュメント

Railsには次の2つのドキュメントがある;

Ruby on Rails Guides - help you learn about Ruby on Rails,
APIドキュメント - serves as a reference.

また、それぞれにガイドラインがあるので読んでみよう。

それから、ドキュメントの変更だけの場合はCIを動かす必要はない。 [ci skip] をつけよう。

🚌 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 issue number. GH#1234
 
    *Your Name*

🗽 コミットメッセージ

コミットは1つにsquashしておこう。そして、コミットメッセージも簡単なサマリーをちゃんと書こう。

Short summary (ideally 50 characters or less)
 
More detailed description, if necessary. It should be wrapped to
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 checkout master
$ git pull --rebase

$ git checkout my_new_branch
$ git rebase master

🐹 Forkしよう

# 自分のリポジトリをForkして作ろう
$ git remote add mine git@github.com:/rails.git
# 自分のリポジトリへのpush
$ git push mine my_new_branch

# rails 本家のブランチをremoteに追加
$ git remote add rails git://github.com/rails/rails.git

# rails 本家をfetch
$ git fetch rails

# rails/masterでリベースしよう
$ git checkout master
$ git rebase rails/master

🤔 バックポーティング(BackPorting)

次のメジャーリリースまでにHEADの変更を取り込みたい場合は、patchを作って自分のブランチに適用しよう。

# master と HEAD(現在のブランチ)とのdiffを取る
$ git log master..HEAD

# patchを作ろう
$ git format-patch master --stdout > ~/my_changes.patch

# 自分のブランチにpatchを適用仕様
$ git checkout -b my_backport_branch 3-2-stable
$ git apply ~/my_changes.patch

🐠 開発環境の構築

VirtualBoxを使って簡単に構築したい場合 => rails/rails-dev-box: A virtual machine for Ruby on Rails core development - GitHub
ローカルに構築したい場合 => Development Dependencies Install — Ruby on Rails Guides

🗻 テスト用のアプリケーションを作る

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

🐯 コントリビューターの一覧

Rails Contributors

🚜 あとがき

英語のドキュメントを読みながら書いたので間違っている部分も多々あると思います。もしお気付きの点等あれば @zyunnosuke まで

🎃 参考リンク

🖥 VULTRおすすめ

「VULTR」はVPSサーバのサービスです。日本にリージョンがあり、最安は512MBで2.5ドル/月($0.004/時間)で借りることができます。4GBメモリでも月20ドルです。最近はVULTRのヘビーユーザーになので、「ここ」から会員登録してもらえるとサービス開発が捗ります！

酒と泪とRubyとRailsと