- Railsにプルリクストを送るときに知っておくと便利なお作法集
- Railsにプルリクエストを送りたいけど何から始めたらいいのかわからない人向けの指針
お作法についてはRuby on Rails に貢献する方法 | Rails ガイドを参考にしています。
Railsのコードを読むには、最低限次の二つの知識があったほうがよいです
- メタプログラミングRubyを読了した程度のRubyの知識
- 読もうとしている機能に関する知識をRuby on Rails ガイドなどで得ておく
- rails 自体のテストは rails-dev-box にある vagrant 環境越しにやります
- 基本的に各ライブラリ(例: activerecord)のディレクトリで rake test して実行します。全体は時間かかりすぎる><
bundle exec ruby -w -Itest:lib テストファイル名
ex)
bundle exec ruby -w -Itest:lib test/core_ext/hash_ext_test.rb
bundle exec ruby -w -Itest:lib テストファイル名 -n テスト名
ex)
bundle exec ruby -w -Itest:lib test/core_ext/hash_ext_test.rb -n test_transform_keys
- Issue にテンプレートがあるのでそれを埋めましょう
- 再現コードのひな形あるのでそれを参考に動く再現手順を作りましょう
- 他の人が作ったIssueに再現手順がなかったら、つくってあげると喜ばれるかも
- ドキュメントやコメントの typo 修正は、コミットに
[ci skip]
を必ずつけること - PRのテンプレートがあるのでなるべく埋めましょう
- コミットはなるべく一つにまとめましょう
- PRした後に指摘来たらsquashせずにコミットを追加
- マージする段階になったらsquashしてねと言われるはず
- バグ修正以外のPRは、「このPRが入るとなにが良くなるのか」をなるべく具体的に書きましょう
- ここが明確でないPRは放置されたりcloseされたりしがち
- edge Rails をなるべく毎日さわる。
- 新機能が追加されたら一通り使ってみるとバグに気づきやすい
TODO:
やFIXME:
で検索する- DHH が立てた Issue をウォッチする
- コミットを読む
- なるようになるブログ をウォッチするとべんり
- コードを読む
- 最初は ActiveSupport が読みやすいのでオススメ
- マージされると Rails Contributors に自分の名前が載るので見てニヤニヤしましょう
登録したOSSのPRやIssueを毎日メールで通知してくれる
- rails は travis ci を使っているけれど、どうやら rails を fork したプロジェクトでは travis を動かせない模様
私はあと以下のような事を気にしてたりします。ご参考までに。
hash
cache · rails/rails@13c4cc3ARCONN
でDBを指定してテストを行う。 また、DBに依存しないテストを行いたい場合は、SQLite3のin-memory DBを使用する。大分早くい。詳細はRUNNING_UNIT_TESTS.rdoc参照。