Chapter 3: numerous pedantic cleanups and rewording

book/03-git-branching/sections/basic-branching-and-merging.asc

@@ -186,7 +186,7 @@ $ git branch -d iss53
 
 (((merging, conflicts)))
 Occasionally, this process doesn't go smoothly.
-If you changed the same part of the same file differently in the two branches you're merging together, Git won't be able to merge them cleanly.
+If you changed the same part of the same file differently in the two branches you're merging, Git won't be able to merge them cleanly.
 If your fix for issue #53 modified the same part of a file as the `hotfix` branch, you'll get a merge conflict that looks something like this:
 
 [source,console]

book/03-git-branching/sections/nutshell.asc

@@ -20,7 +20,7 @@ $ git commit -m 'The initial commit of my project'
 When you create the commit by running `git commit`, Git checksums each subdirectory (in this case, just the root project directory) and stores those tree objects in the Git repository.
 Git then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed.(((git commands, commit)))
 
-Your Git repository now contains five objects: three blobs (each representing the contents of one of the three files), one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata.
+Your Git repository now contains five objects: three _blobs_ (each representing the contents of one of the three files), one _tree_ that lists the contents of the directory and specifies which file names are stored as which blobs, and one _commit_ with the pointer to that root tree and all the commit metadata.
 
 .A commit and its tree
 image::images/commit-and-tree.png[A commit and its tree.]
@@ -49,7 +49,7 @@ image::images/branch-and-history.png[A branch and its commit history.]
 ==== Creating a New Branch
 
 (((branches, creating)))
-What happens if you create a new branch?
+What happens when you create a new branch?
 Well, doing so creates a new pointer for you to move around.
 Let's say you want to create a new branch called `testing`.
 You do this with the `git branch` command:(((git commands, branch)))

book/03-git-branching/sections/rebasing.asc

@@ -20,9 +20,9 @@ image::images/basic-rebase-2.png[Merging to integrate diverged work history.]
 
 However, there is another way: you can take the patch of the change that was introduced in `C4` and reapply it on top of `C3`.
 In Git, this is called _rebasing_.
-With the `rebase` command, you can take all the changes that were committed on one branch and replay them on another one.(((git commands, rebase)))
+With the `rebase` command, you can take all the changes that were committed on one branch and replay them on a different branch.(((git commands, rebase)))
 
-In this example, you'd run the following:
+For this example, you would check out the `experiment` branch, and then rebase it onto the `master` branch as follows:
 
 [source,console]
 ----
@@ -32,7 +32,7 @@ First, rewinding head to replay your work on top of it...
 Applying: added staged command
 ----
 
-It works by going to the common ancestor of the two branches (the one you're on and the one you're rebasing onto), getting the diff introduced by each commit of the branch you're on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn.
+This operation works by going to the common ancestor of the two branches (the one you're on and the one you're rebasing onto), getting the diff introduced by each commit of the branch you're on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn.
 
 .Rebasing the change introduced in `C4` onto `C3`
 image::images/basic-rebase-3.png[Rebasing the change introduced in `C4` onto `C3`.]
@@ -56,7 +56,7 @@ Often, you'll do this to make sure your commits apply cleanly on a remote branch
 In this case, you'd do your work in a branch and then rebase your work onto `origin/master` when you were ready to submit your patches to the main project.
 That way, the maintainer doesn't have to do any integration work -- just a fast-forward or a clean apply.
 
-Note that the snapshot pointed to by the final commit you end up with, whether it's the last of the rebased commits for a rebase or the final merge commit after a merge, is the same snapshot – it's only the history that is different.
+Note that the snapshot pointed to by the final commit you end up with, whether it's the last of the rebased commits for a rebase or the final merge commit after a merge, is the same snapshot -- it's only the history that is different.
 Rebasing replays changes from one line of work onto another in the order they were introduced, whereas merging takes the endpoints and merges them together.
 
 ==== More Interesting Rebases

book/03-git-branching/sections/remote-branches.asc

@@ -10,7 +10,7 @@ Remote-tracking branches are references to the state of remote branches.
 They're local references that you can't move; Git moves them for you whenever you do any network communication, to make sure they accurately represent the state of the remote repository.
 Think of them as bookmarks, to remind you where the branches in your remote repositories were the last time you connected to them.
 
-Remote-tracking branches take the form `<remote>/<branch>`.
+Remote-tracking branch names take the form `<remote>/<branch>`.
 For instance, if you wanted to see what the `master` branch on your `origin` remote looked like as of the last time you communicated with it, you would check the `origin/master` branch.
 If you were working on an issue with a partner and they pushed up an `iss53` branch, you might have your own local `iss53` branch, but the branch on the server would be represented by the remote-tracking branch `origin/iss53`.
 
@@ -36,7 +36,7 @@ Also, as long as you stay out of contact with your origin server, your `origin/m
 .Local and remote work can diverge
 image::images/remote-branches-2.png[Local and remote work can diverge.]
 
-To synchronize your work, you run a `git fetch origin` command.
+To synchronize your work with a given remote, you run a `git fetch <remote>` command (in our case, `git fetch origin`).
 This command looks up which server ``origin'' is (in this case, it's `git.ourcompany.com`), fetches any data from it that you don't yet have, and updates your local database, moving your `origin/master` pointer to its new, more up-to-date position.
 
 .`git fetch` updates your remote-tracking branches
@@ -60,7 +60,7 @@ image::images/remote-branches-5.png[Remote tracking branch for `teamone/master`.
 ==== Pushing
 
 (((pushing)))
-When you want to share a branch with the world, you need to push it up to a remote that you have write access to.
+When you want to share a branch with the world, you need to push it up to a remote to which you have write access.
 Your local branches aren't automatically synchronized to the remotes you write to -- you have to explicitly push the branches you want to share.
 That way, you can use private branches for work you don't want to share, and push up only the topic branches you want to collaborate on.
 
@@ -112,7 +112,7 @@ From https://github.com/schacon/simplegit
 ----
 
 It's important to note that when you do a fetch that brings down new remote-tracking branches, you don't automatically have local, editable copies of them.
-In other words, in this case, you don't have a new `serverfix` branch -- you only have an `origin/serverfix` pointer that you can't modify.
+In other words, in this case, you don't have a new `serverfix` branch -- you have only an `origin/serverfix` pointer that you can't modify.
 
 To merge this work into your current working branch, you can run `git merge origin/serverfix`.
 If you want your own `serverfix` branch that you can work on, you can base it off your remote-tracking branch:
@@ -211,7 +211,7 @@ $ git fetch --all; git branch -vv
 ==== Pulling
 
 (((pulling)))
-While the `git fetch` command will fetch down all the changes on the server that you don't have yet, it will not modify your working directory at all.
+While the `git fetch` command will fetch all the changes on the server that you don't have yet, it will not modify your working directory at all.
 It will simply get the data for you and let you merge it yourself.
 However, there is a command called `git pull` which is essentially a `git fetch` immediately followed by a `git merge` in most cases.
 If you have a tracking branch set up as demonstrated in the last section, either by explicitly setting it or by having it created for you by the `clone` or `checkout` commands, `git pull` will look up what server and branch your current branch is tracking, fetch from that server and then try to merge in that remote branch.
@@ -222,7 +222,7 @@ Generally it's better to simply use the `fetch` and `merge` commands explicitly
 ==== Deleting Remote Branches
 
 (((branches, deleting remote)))
-Suppose you're done with a remote branch – say you and your collaborators are finished with a feature and have merged it into your remote's `master` branch (or whatever branch your stable codeline is in).
+Suppose you're done with a remote branch -- say you and your collaborators are finished with a feature and have merged it into your remote's `master` branch (or whatever branch your stable codeline is in).
 You can delete a remote branch using the `--delete` option to `git push`.
 If you want to delete your `serverfix` branch from the server, you run the following:
 

book/03-git-branching/sections/workflows.asc

@@ -60,4 +60,4 @@ image::images/topic-branches-2.png[History after merging `dumbidea` and `iss91v2
 We will go into more detail about the various possible workflows for your Git project in <<ch05-distributed-git#ch05-distributed-git>>, so before you decide which branching scheme your next project will use, be sure to read that chapter.
 
 It's important to remember when you're doing all this that these branches are completely local.
-When you're branching and merging, everything is being done only in your Git repository -- no server communication is happening.
+When you're branching and merging, everything is being done only in your Git repository -- there is no communication with the server.