Monospace for named commits, slight rewording

Author: ben

en/book/03-git-branching/chapter3.asc

@@ -1,4 +1,3 @@
-
 == Git Branching
 
 Nearly every VCS has some form of branching support. Branching means you diverge from the main line of development and continue to do work without messing with that main line. In many VCS tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects.
@@ -492,7 +491,7 @@ Consider an example of doing some work (on `master`), branching off for an issue
 .Multiple topic branches
 image::images/18333fig0320-tn.png[Multiple topic branches.]
 
-Now, let’s say you decide you like the second solution to your issue best (`iss91v2`); and you showed the `dumbidea` branch to your coworkers, and it turns out to be genius. You can throw away the original `iss91` branch (losing commits C5 and C6) and merge in the other two. Your history then looks like this:
+Now, let’s say you decide you like the second solution to your issue best (`iss91v2`); and you showed the `dumbidea` branch to your coworkers, and it turns out to be genius. You can throw away the original `iss91` branch (losing commits `C5` and `C6`) and merge in the other two. Your history then looks like this:
 
 .History after merging `dumbidea` and `iss91v2`
 image::images/18333fig0321-tn.png[History after merging `dumbidea` and `iss91v2`.]
@@ -625,13 +624,13 @@ If you go back to an earlier example from <<_basic_merging>> (see <<rbdiag_a>>),
 .Simple divergent history
 image::images/18333fig0327-tn.png[Simple divergent history.]
 
-The easiest way to integrate the branches, as we’ve already covered, is the `merge` command. It performs a three-way merge between the two latest branch snapshots (C3 and C4) and the most recent common ancestor of the two (C2), creating a new snapshot (and commit), as shown in <<rbdiag_b>>.
+The easiest way to integrate the branches, as we’ve already covered, is the `merge` command. It performs a three-way merge between the two latest branch snapshots (`C3` and `C4`) and the most recent common ancestor of the two (`C2`), creating a new snapshot (and commit), as shown in <<rbdiag_b>>.
 
 [[rbdiag_b]]
 .Merging to integrate diverged work history
 image::images/18333fig0328-tn.png[Merging to integrate diverged work history.]
 
-However, there is another way: you can take the patch of the change that was introduced in C3 and reapply it on top of C4. 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.
+However, there is another way: you can take the patch of the change that was introduced in `C3` and reapply it on top of `C4`. 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.
 
 In this example, you’d run the following:
 
@@ -654,7 +653,7 @@ At this point, you can go back to the master branch and do a fast-forward merge.
 .Fast-forwarding the master branch
 image::images/18333fig0330-tn.png[Fast-forwarding the master branch.]
 
-Now, the snapshot pointed to by C3' is exactly the same as the one that was pointed to by C5 in the merge example. There is no difference in the end product of the integration, but rebasing makes for a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.
+Now, the snapshot pointed to by `C3'` is exactly the same as the one that was pointed to by `C5` in the merge example. There is no difference in the end product of the integration, but rebasing makes for a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.
 
 Often, you’ll do this to make sure your commits apply cleanly on a remote branch – perhaps in a project to which you’re trying to contribute but that you don’t maintain. 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.
 
@@ -668,7 +667,7 @@ You can also have your rebase replay on something other than the rebase branch.
 .A history with a topic branch off another topic branch
 image::images/18333fig0331-tn.png[A history with a topic branch off another topic branch.]
 
-Suppose you decide that you want to merge your client-side changes into your mainline for a release, but you want to hold off on the server-side changes until it’s tested further. You can take the changes on client that aren’t on server (C8 and C9) and replay them on your master branch by using the `--onto` option of `git rebase`:
+Suppose you decide that you want to merge your client-side changes into your mainline for a release, but you want to hold off on the server-side changes until it’s tested further. You can take the changes on client that aren’t on server (`C8` and `C9`) and replay them on your master branch by using the `--onto` option of `git rebase`:
 
 [source,shell]
 ----
@@ -758,10 +757,10 @@ image::images/18333fig0339-tn.png[You merge in the same work again into a new me
 
 If you run a `git log` when your history looks like this, you’ll see two commits that have the same author, date, and message, which will be confusing.
 Furthermore, if you push this history back up to the server, you’ll reintroduce all those rebased commits to the central server, which can further confuse people.
-It's pretty safe to assume that the other developer doesn't want C4 and C6 to be in the history; that's why she rebased in the first place.
+It's pretty safe to assume that the other developer doesn't want `C4` and `C6` to be in the history; that's why she rebased in the first place.
 
 Fortunately, Git has a feature to make this easier.
-If you use the `--rebase` flag to `git pull`, Git will do a fetch (which updates the remote branch to C4') followed by a _rebase_, rather than a merge.
+If you use the `--rebase` flag to `git pull`, Git will do a fetch (which updates the remote branch to `C4'`) followed by a _rebase_, rather than a merge.
 This is exactly what you want; your local commits will follow the new remote commits in a straight line, and the abandoned commits will stay lost.
 
 In fact, this functionality is so useful, that you can make that flag the default; simply do `git config --global pull.rebase true`.
@@ -789,8 +788,7 @@ You wouldn't publish the first draft of a book, and the manual for how to mainta
 This is the camp that uses tools like rebase and filter-branch when they are appropriate for telling the story in the way that's best for future readers.
 If that requires a force-push every now and then, so be it.
 
-Now back to the question of which is better.
-Hopefully you'll see that it's not that simple.
+Now, to the question of whether merging or rebasing is better: hopefully you'll see that it's not that simple.
 Git is a powerful tool, and allows you to do many things to and with your history, but every team and every project is different.
 Now that you know how both of these things work, it's up to you to decide which one is best for your particular situation.