Added a few changes to two sections of Chapter 5

 * changed "cherry pick" to "cherry-pick" for consistency
 * monospaced a few git commands
 * monospaced a few branch names
 * added "git request-pull" command to a code example
 * added a word that would probably improve a sentence
 * changed a git output to be consistent with that shown git
 * changed a sentence to be more readable

Author: Kaartic Sivaraam

book/05-distributed-git/sections/contributing.asc

@@ -520,8 +520,8 @@ $ git remote add myfork (url)
 
 Then you need to push your work up to it.
 It's easiest to push the topic branch you're working on up to your repository, rather than merging into your master branch and pushing that up.
-The reason is that if the work isn't accepted or is cherry picked, you don't have to rewind your master branch.
-If the maintainers merge, rebase, or cherry-pick your work, you'll eventually get it back via pulling from their repository anyhow:
+The reason is that if the work isn't accepted or is cherry-picked, you don't have to rewind your master branch.
+If the maintainers `merge`, `rebase`, or `cherry-pick` your work, you'll eventually get it back via pulling from their repository anyhow:
 
 [source,console]
 ----
@@ -566,6 +566,7 @@ $ git checkout -b featureB origin/master
 # (work)
 $ git commit
 $ git push myfork featureB
+$ git request-pull origin/master myfork
 # (email maintainer)
 $ git fetch origin
 ----

book/05-distributed-git/sections/maintaining.asc

@@ -197,7 +197,7 @@ $ git fetch jessica
 $ git checkout -b rubyclient jessica/ruby-client
 ----
 
-If she emails you again later with another branch containing another great feature, you can fetch and check out because you already have the remote setup.
+If she emails you again later with another branch containing another great feature, you could directly `fetch` and `checkout` because you already have the remote setup.
 
 This is most useful if you're working with a person consistently.
 If someone only has a single patch to contribute once in a while, then accepting it over email may be less time consuming than requiring everyone to run their own server and having to continually add and remove remotes to get a few patches.
@@ -215,7 +215,7 @@ This does a one-time pull and doesn't save the URL as a remote reference:
 $ git pull https://github.com/onetimeguy/project
 From https://github.com/onetimeguy/project
  * branch            HEAD       -> FETCH_HEAD
-Merge made by recursive.
+Merge made by the 'recursive' strategy.
 ----
 
 [[_what_is_introduced]]
@@ -297,7 +297,7 @@ You have a number of choices, so we'll cover a few of them.
 ===== Merging Workflows
 
 (((workflows, merging)))
-One simple workflow merges your work into your `master` branch.
+One simple workflow is to merge the work into your `master` branch.
 In this scenario, you have a `master` branch that contains basically stable code.
 When you have work in a topic branch that you've done or that someone has contributed and you've verified, you merge it into your master branch, delete the topic branch, and then continue the process.
 If we have a repository with work in two branches named `ruby_client` and `php_client` that looks like <<merwf_a>> and merge `ruby_client` first and then `php_client` next, then your history will end up looking like <<merwf_b>>.
@@ -329,9 +329,9 @@ image::images/merging-workflows-4.png[After a topic branch merge.]
 .After a project release.
 image::images/merging-workflows-5.png[After a topic branch release.]
 
-This way, when people clone your project's repository, they can either check out master to build the latest stable version and keep up to date on that easily, or they can check out develop, which is the more cutting-edge stuff.
-You can also continue this concept, having an integrate branch where all the work is merged together.
-Then, when the codebase on that branch is stable and passes tests, you merge it into a develop branch; and when that has proven itself stable for a while, you fast-forward your master branch.
+This way, when people clone your project's repository, they can either check out `master` to build the latest stable version and keep up to date on that easily, or they can check out `develop`, which is the more cutting-edge stuff.
+You can also extend this concept by having an `integrate` branch where all the work is merged together.
+Then, when the codebase on that branch is stable and passes tests, you merge it into a `develop` branch; and when that has proven itself stable for a while, you fast-forward your `master` branch.
 
 ===== Large-Merging Workflows
 
@@ -357,7 +357,7 @@ The Git project also has a `maint` branch that is forked off from the last relea
 Thus, when you clone the Git repository, you have four branches that you can check out to evaluate the project in different stages of development, depending on how cutting edge you want to be or how you want to contribute; and the maintainer has a structured workflow to help them vet new contributions.
 
 [[_rebase_cherry_pick]]
-===== Rebasing and Cherry Picking Workflows
+===== Rebasing and Cherry-Picking Workflows
 
 (((workflows, rebasing and cherry-picking)))
 Other maintainers prefer to rebase or cherry-pick contributed work on top of their master branch, rather than merging it in, to keep a mostly linear history.