1 files changed, 13 insertions, 13 deletions
diff --git a/guides/source/contributing_to_ruby_on_rails.textile b/guides/source/contributing_to_ruby_on_rails.textile
index dd43ef795f..5a3ebe10c9 100644
--- a/guides/source/contributing_to_ruby_on_rails.textile
+++ b/guides/source/contributing_to_ruby_on_rails.textile
@@ -42,12 +42,12 @@ To move on from submitting bugs to helping resolve existing issues or contributi
 
 h4. Install Git
 
-Ruby on Rails uses git for source code control. The "git homepage":http://git-scm.com/ has installation instructions. There are a variety of resources on the net that will help you get familiar with git:
+Ruby on Rails uses Git for source code control. The "Git homepage":http://git-scm.com/ has installation instructions. There are a variety of resources on the net that will help you get familiar with Git:
 
-* "Everyday Git":http://schacon.github.com/git/everyday.html will teach you just enough about git to get by.
-* The "PeepCode screencast":https://peepcode.com/products/git on git ($9) is easier to follow.
-* "GitHub":http://help.github.com offers links to a variety of git resources.
-* "Pro Git":http://progit.org/book/ is an entire book about git with a Creative Commons license.
+* "Everyday Git":http://schacon.github.com/git/everyday.html will teach you just enough about Git to get by.
+* The "PeepCode screencast":https://peepcode.com/products/git on Git ($9) is easier to follow.
+* "GitHub":http://help.github.com offers links to a variety of Git resources.
+* "Pro Git":http://git-scm.com/book is an entire book about Git with a Creative Commons license.
 
 h4. Clone the Ruby on Rails Repository
 
@@ -74,7 +74,7 @@ If you are on Fedora or CentOS, you can run
 $ sudo yum install libxml2 libxml2-devel libxslt libxslt-devel
 </shell>
 
-If you have any problems with these libraries, you should install them manually compiling the source code. Just follow the instructions "here":http://nokogiri.org/tutorials/installing_nokogiri.html#red_hat__centos .
+If you have any problems with these libraries, you should install them manually compiling the source code. Just follow the instructions at the "Red Hat/CentOS section of the Nokogiri tutorials":http://nokogiri.org/tutorials/installing_nokogiri.html#red_hat__centos .
 
 Also, SQLite3 and its development files for the +sqlite3-ruby+ gem -- in Ubuntu you're done with just
 
@@ -250,7 +250,7 @@ $ git branch --track 3-0-stable origin/3-0-stable
 $ git checkout 3-0-stable
 </shell>
 
-TIP: You may want to "put your git branch name in your shell prompt":http://qugstart.com/blog/git-and-svn/add-colored-git-branch-name-to-your-shell-prompt/ to make it easier to remember which version of the code you're working with.
+TIP: You may want to "put your Git branch name in your shell prompt":http://qugstart.com/blog/git-and-svn/add-colored-git-branch-name-to-your-shell-prompt/ to make it easier to remember which version of the code you're working with.
 
 h3. Helping to Resolve Existing Issues
 
@@ -331,7 +331,7 @@ $ cd rails
 $ git checkout -b my_new_branch
 </shell>
 
-It doesn’t matter much what name you use, because this branch will only exist on your local computer and your personal repository on Github. It won't be part of the Rails git repository.
+It doesn’t matter much what name you use, because this branch will only exist on your local computer and your personal repository on Github. It won't be part of the Rails Git repository.
 
 h4. Write Your Code
 
@@ -367,7 +367,7 @@ You might want also to check out the "RailsBridge BugMash":http://wiki.railsbrid
 
 h4. Commit Your Changes
 
-When you're happy with the code on your computer, you need to commit the changes to git:
+When you're happy with the code on your computer, you need to commit the changes to Git:
 
 <shell>
 $ git commit -a
@@ -386,7 +386,7 @@ 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
+Description can have multiple paragraphs and you can use code examples
 inside, just indent it with 4 spaces:
 
     class PostsController
@@ -495,7 +495,7 @@ It’s entirely possible that the feedback you get will suggest changes. Don’t
 
 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.
+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 changes 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.
 
@@ -520,9 +520,9 @@ $ git apply ~/my_changes.patch
 
 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.
+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!
+And then... think about your next contribution!
 
 h3. Rails Contributors