Merge pull request #704 from sivaraam/changes

A few changes to chapter 5

Author: ben

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

@@ -520,7 +520,7 @@ $ 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.
+The reason is that if the work isn't accepted or is cherry-picked, you don't have to rewind your master branch. (`cherry-pick` is covered in more detail in <<_rebase_cherry_pick>>).
 If the maintainers `merge`, `rebase`, or `cherry-pick` your work, you'll eventually get it back via pulling from their repository anyhow:
 
 [source,console]

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

@@ -12,7 +12,7 @@ When you're thinking of integrating new work, it's generally a good idea to try
 This way, it's easy to tweak a patch individually and leave it if it's not working until you have time to come back to it.
 If you create a simple branch name based on the theme of the work you're going to try, such as `ruby_client` or something similarly descriptive, you can easily remember it if you have to abandon it for a while and come back later.
 The maintainer of the Git project tends to namespace these branches as well – such as `sc/ruby_client`, where `sc` is short for the person who contributed the work.
-As you'll remember, you can create the branch based off your master branch like this:
+As you'll remember, you can create the branch based off your `master` branch like this:
 
 [source,console]
 ----
@@ -26,7 +26,7 @@ Or, if you want to also switch to it immediately, you can use the `checkout -b`
 $ git checkout -b sc/ruby_client master
 ----
 
-Now you're ready to add your contributed work into this topic branch and determine if you want to merge it into your longer-term branches.
+Now you're ready to add the contributed work that you received into this topic branch and determine if you want to merge it into your longer-term branches.
 
 [[_patches_from_email]]
 ==== Applying Patches from Email
@@ -73,7 +73,7 @@ If the contributor is a Git user and was good enough to use the `format-patch` c
 If you can, encourage your contributors to use `format-patch` instead of `diff` to generate patches for you.
 You should only have to use `git apply` for legacy patches and things like that.
 
-To apply a patch generated by `format-patch`, you use `git am`.
+To apply a patch generated by `format-patch`, you use `git am` (the command is named `am` as it is used to "apply a series of patches from a mailbox").
 Technically, `git am` is built to read an mbox file, which is a simple, plain-text format for storing one or more email messages in one text file.
 It looks something like this:
 
@@ -346,7 +346,8 @@ If they're safe, they're merged into `next`, and that branch is pushed up so eve
 image::images/large-merges-1.png[Managing a complex series of parallel contributed topic branches.]
 
 If the topics still need work, they're merged into `pu` instead.
-When it's determined that they're totally stable, the topics are re-merged into `master` and are then rebuilt from the topics that were in `next` but didn't yet graduate to `master`.
+When it's determined that they're totally stable, the topics are re-merged into `master`.
+The `next` and `pu` branches are then rebuilt from the `master`.
 This means `master` almost always moves forward, `next` is rebased occasionally, and `pu` is rebased even more often:
 
 .Merging contributed topic branches into long-term integration branches.
@@ -355,6 +356,7 @@ image::images/large-merges-2.png[Merging contributed topic branches into long-te
 When a topic branch has finally been merged into `master`, it's removed from the repository.
 The Git project also has a `maint` branch that is forked off from the last release to provide backported patches in case a maintenance release is required.
 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.
+The Git project's workflow is specialized. To clearly understand this you could check out the https://github.com/git/git/blob/master/Documentaion/howto/maintain-git.txt[Git Maintainer's guide].
 
 [[_rebase_cherry_pick]]
 ===== Rebasing and Cherry-Picking Workflows