diff options
Diffstat (limited to 'guides/source/contributing_to_ruby_on_rails.textile')
| -rw-r--r-- | guides/source/contributing_to_ruby_on_rails.textile | 103 |
1 files changed, 101 insertions, 2 deletions
diff --git a/guides/source/contributing_to_ruby_on_rails.textile b/guides/source/contributing_to_ruby_on_rails.textile index df475a2359..b52cd6c6b6 100644 --- a/guides/source/contributing_to_ruby_on_rails.textile +++ b/guides/source/contributing_to_ruby_on_rails.textile @@ -109,7 +109,7 @@ You can run any single test separately too: <shell> $ cd actionpack -$ ruby -Itest test/template/form_helper_test.rb +$ bundle exec ruby -Itest test/template/form_helper_test.rb </shell> h4. Warnings @@ -190,6 +190,8 @@ $ rake postgresql:build_databases NOTE: Using the rake task to create the test databases ensures they have the correct character set and collation. +NOTE: You'll see the following warning (or localized warning) during activating HStore extension in PostgreSQL 9.1.x or earlier: "WARNING: => is deprecated as an operator". + If you’re using another database, check the files under +activerecord/test/connections+ for default connection information. You can edit these files to provide different credentials on your machine if you must, but obviously you should not push any such changes back to Rails. You can now run the tests as you did for +sqlite3+. The tasks are respectively @@ -317,6 +319,8 @@ Now get busy and add or edit code. You’re on your branch now, so you can write * Include tests that fail without your code, and pass with it. * Update the (surrounding) documentation, examples elsewhere, and the guides: whatever is affected by your contribution. +TIP: Changes that are cosmetic in nature and do not add anything substantial to the stability, functionality, or testability of Rails will generally not be accepted. + h4. Follow the Coding Conventions Rails follows a simple set of coding style conventions. @@ -343,9 +347,39 @@ h4. Commit Your Changes When you're happy with the code on your computer, you need to commit the changes to git: <shell> -$ git commit -a -m "Here is a commit message on what I changed in this commit" +$ git commit -a </shell> +At this point, your editor should be fired up and you can write a message for this commit. Well formatted and descriptive commit messages are extremely helpful for the others, especially when figuring out why given change was made, so please take the time to write it. + +Good commit message should be formatted according to the following example: + +<plain> +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. You +should add such description also if it's already present in bug tracker, +it should not be necessary to visit a webpage to check the history. + +Description can have multiple paragraps and you can use code examples +inside, just indent it with 4 spaces: + + class PostsController + def index + respond_with Post.limit(10) + end + end + +You can also add bullet points: + +- you can use dashes or asterisks + +- also, try to indent next line of a point for readability, if it's too + long to fit in 72 characters +</plain> + TIP. Please squash your commits into a single commit when appropriate. This simplifies future cherry picks, and also keeps the git log clean. h4. Update Master @@ -382,6 +416,42 @@ Push to your remote: $ git push mine my_new_branch </shell> +You might have cloned your forked repository into your machine and might want to add the original Rails repository as a remote instead, if that's the case here's what you have to do. + +In the directory you cloned your fork: + +<shell> +$ git remote add rails git://github.com/rails/rails.git +</shell> + +Download new commits and branches from the official repository: + +<shell> +$ git fetch rails +</shell> + +Merge the new content: + +<shell> +$ git checkout master +$ git rebase rails/master +</shell> + +Update your fork: + +<shell> +$ git push origin master +</shell> + +If you want to update another branches: + +<shell> +$ git checkout branch_name +$ git rebase rails/branch_name +$ git push origin branch_name +</shell> + + h4. Issue a Pull Request Navigate to the Rails repository you just pushed to (e.g. https://github.com/your-user-name/rails) and press "Pull Request" in the upper right hand corner. @@ -400,6 +470,35 @@ h4. Iterate as Necessary It’s entirely possible that the feedback you get will suggest changes. Don’t get discouraged: the whole point of contributing to an active open source project is to tap into community knowledge. If people are encouraging you to tweak your code, then it’s worth making the tweaks and resubmitting. If the feedback is that your code doesn’t belong in the core, you might still think about releasing it as a gem. +h4. Backporting + +Changes that are merged into master are intended for the next major release of Rails. Sometimes, it might be beneficial for your changes to propagate back to the maintenance releases for older stable branches. Generally, security fixes and bug fixes are good candidates for a backport, while new features and patches that introduce a change in behavior will not be accepted. When in doubt, it is best to consult a rails team member before backporting your changes to avoid wasted effort. + +For simple fixes, the easiest way to backport your change is to "extract a diff from your changes in master and apply them to the target branch":http://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git. + +First make sure your changes are the only difference between your current branch and master: + +<shell> +$ git log master..HEAD +</shell> + +Then extract the diff: + +<shell> +$ git format-patch master --stdout > ~/my_changes.patch +</shell> + +Switch over to the target branch and apply your changes: + +<shell> +$ git checkout -b my_backport_branch 3-2-stable +$ git apply ~/my_changes.patch +</shell> + +This works well for simple changes. However, if your changes are complicated or if the code in master has deviated significantly from your target branch, it might require more work on your part. The difficulty of a backport varies greatly from case to case, and sometimes it is simply not worth the effort. + +Once you have resolved all conflicts and made sure all the tests are passing, push your changes and open a separate pull request for your backport. It is also worth noting that older branches might have a different set of build targets than master. When possible, it is best to first test your backport locally against the ruby versions listed in +.travis.yml+ before submitting your pull request. + And then ... think about your next contribution! h3. Rails Contributors |