proper casing in pronouns; relocate the pro git book [ci skip]

- Cases in point - GitHub, Git, Twitter and Rails should start
  with capitals when used outside code context
- Pro Git found - URL has been updated for its new home
- Faces for links - More descriptive titles on link prompt
  instead of "here"

RELEASING_RAILS.rdoc

@@ -25,10 +25,10 @@ for Rails.  You can check the status of his tests here:
 
 Do not release with Red AWDwR tests.
 
-=== Do we have any git dependencies?  If so, contact those authors.
+=== Do we have any Git dependencies?  If so, contact those authors.
 
-Having git dependencies indicates that we depend on unreleased code.
-Obviously rails cannot be released when it depends on unreleased code.
+Having Git dependencies indicates that we depend on unreleased code.
+Obviously Rails cannot be released when it depends on unreleased code.
 Contact the authors of those particular gems and work out a release date that
 suits them.
 
@@ -115,14 +115,14 @@ what to do in case anything goes wrong:
 === Send Rails release announcements
 
 Write a release announcement that includes the version, changes, and links to
-github where people can find the specific commit list.  Here are the mailing
+GitHub where people can find the specific commit list.  Here are the mailing
 lists where you should announce:
 
 * rubyonrails-core@googlegroups.com
 * rubyonrails-talk@googlegroups.com
 * ruby-talk@ruby-lang.org
 
-Use markdown format for your announcement.  Remember to ask people to report
+Use Markdown format for your announcement.  Remember to ask people to report
 issues with the release candidate to the rails-core mailing list.
 
 IMPORTANT: If any users experience regressions when using the release
@@ -131,16 +131,16 @@ break existing applications.
 
 === Post the announcement to the Rails blog.
 
-If you used markdown format for your email, you can just paste it in to the
+If you used Markdown format for your email, you can just paste it in to the
 blog.
 
 * http://weblog.rubyonrails.org
 
-=== Post the announcement to the Rails twitter account.
+=== Post the announcement to the Rails Twitter account.
 
 == Time between release candidate and actual release
 
-Check the rails-core mailing list and the github issue list for regressions in
+Check the rails-core mailing list and the GitHub issue list for regressions in
 the RC.
 
 If any regressions are found, fix the regressions and repeat the release
@@ -167,7 +167,7 @@ Today, do this stuff in this order:
 * Email security lists
 * Email general announcement lists
 
-=== Emailing the rails security announce list
+=== Emailing the Rails security announce list
 
 Email the security announce list once for each vulnerability fixed.
 

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
 

guides/source/initialization.textile

@@ -17,7 +17,7 @@ NOTE: Paths in this guide are relative to Rails or a Rails application unless ot
 
 TIP: If you want to follow along while browsing the Rails "source
 code":https://github.com/rails/rails, we recommend that you use the +t+
-key binding to open the file finder inside github and find files
+key binding to open the file finder inside GitHub and find files
 quickly.
 
 h3. Launch!
@@ -359,7 +359,7 @@ set earlier) is required.
 h4. +config/application+
 
 When +require APP_PATH+ is executed, +config/application.rb+ is loaded.
-This is a file exists in your app and it's free for you to change based
+This file exists in your app and it's free for you to change based
 on your needs.
 
 h4. +Rails::Server#start+
@@ -453,7 +453,7 @@ end
 
 The interesting part for a Rails app is the last line, +server.run+. Here we encounter the +wrapped_app+ method again, which this time
 we're going to explore more (even though it was executed before, and
-thus memoized by now).
+thus memorized by now).
 
 <ruby>
 @wrapped_app ||= build_app app
@@ -540,12 +540,12 @@ end
 </ruby>
 
 This is where all the Rails frameworks are loaded and thus made
-available to the application. We wont go into detail of what happens
+available to the application. We won't go into detail of what happens
 inside each of those frameworks, but you're encouraged to try and
 explore them on your own.
 
 For now, just keep in mind that common functionality like Rails engines,
-I18n and Rails configuration is all bein defined here.
+I18n and Rails configuration is all being defined here.
 
 h4. Back to +config/environment.rb+
 
@@ -657,10 +657,10 @@ def self.run(app, options={})
 end
 </ruby>
 
-We wont dig into the server configuration itself, but this is
+We won't dig into the server configuration itself, but this is
 the last piece of our journey in the Rails initialization process.
 
-This high level overview will help you understand when you code is
+This high level overview will help you understand when your code is
 executed and how, and overall become a better Rails developer. If you
 still want to know more, the Rails source code itself is probably the
 best place to go next.

guides/source/plugins.textile

@@ -13,7 +13,7 @@ After reading this guide you should be familiar with:
 
 This guide describes how to build a test-driven plugin that will:
 
-* Extend core ruby classes like Hash and String
+* Extend core Ruby classes like Hash and String
 * Add methods to ActiveRecord::Base in the tradition of the 'acts_as' plugins
 * Give you information about where to put generators in your plugin.
 
@@ -28,7 +28,7 @@ h3. Setup
 _"vendored plugins"_ were available in previous versions of Rails, but they are deprecated in
 Rails 3.2, and will not be available in the future. 
 
-Currently, Rails plugins are built as gems, _gemified plugins_. They can be shared accross 
+Currently, Rails plugins are built as gems, _gemified plugins_. They can be shared across 
 different rails applications using RubyGems and Bundler if desired. 
 
 h4. Generate a gemified plugin.
@@ -392,7 +392,7 @@ the creation of generators can be found in the "Generators Guide":generators.htm
 h3. Publishing your Gem
 
 Gem plugins currently in development can easily be shared from any Git repository. To share the Yaffle gem with others, simply
-commit the code to a Git repository (like Github) and add a line to the Gemfile of the application in question:
+commit the code to a Git repository (like GitHub) and add a line to the Gemfile of the application in question:
 
 <ruby>
 gem 'yaffle', :git => 'git://github.com/yaffle_watcher/yaffle.git'
@@ -401,7 +401,7 @@ gem 'yaffle', :git => 'git://github.com/yaffle_watcher/yaffle.git'
 After running +bundle install+, your gem functionality will be available to the application.
 
 When the gem is ready to be shared as a formal release, it can be published to "RubyGems":http://www.rubygems.org.
-For more information about publishing gems to RubyGems, see: "http://blog.thepete.net/2010/11/creating-and-publishing-your-first-ruby.html":http://blog.thepete.net/2010/11/creating-and-publishing-your-first-ruby.html
+For more information about publishing gems to RubyGems, see: "Creating and Publishing Your First Ruby Gem":http://blog.thepete.net/2010/11/creating-and-publishing-your-first-ruby.html
 
 h3. RDoc Documentation
 
@@ -414,7 +414,7 @@ The first step is to update the README file with detailed information about how
 * How to add the functionality to the app (several examples of common use cases)
 * Warnings, gotchas or tips that might help users and save them time
 
-Once your README is solid, go through and add rdoc comments to all of the methods that developers will use. It's also customary to add '#:nodoc:' comments to those parts of the code that are not included in the public api.
+Once your README is solid, go through and add rdoc comments to all of the methods that developers will use. It's also customary to add '#:nodoc:' comments to those parts of the code that are not included in the public API.
 
 Once your comments are good to go, navigate to your plugin directory and run:
 
@@ -425,6 +425,6 @@ $ rake rdoc
 h4. References
 
 * "Developing a RubyGem using Bundler":https://github.com/radar/guides/blob/master/gem-development.md
-* "Using Gemspecs As Intended":http://yehudakatz.com/2010/04/02/using-gemspecs-as-intended/
+* "Using .gemspecs as Intended":http://yehudakatz.com/2010/04/02/using-gemspecs-as-intended/
 * "Gemspec Reference":http://docs.rubygems.org/read/chapter/20
-* "GemPlugins":http://www.intridea.com/blog/2008/6/11/gemplugins-a-brief-introduction-to-the-future-of-rails-plugins
+* "GemPlugins: A Brief Introduction to the Future of Rails Plugins":http://www.intridea.com/blog/2008/6/11/gemplugins-a-brief-introduction-to-the-future-of-rails-plugins