Fix formatting

Author: Morganov

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

@@ -73,7 +73,7 @@ Finally, you went back to your server branch and did a few more commits.
 image::images/interesting-rebase-1.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`:
+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,console]
 ----
@@ -99,7 +99,7 @@ $ git merge client
 image::images/interesting-rebase-3.png[Fast-forwarding your master branch to include the client branch changes.]
 
 Let's say you decide to pull in your server branch as well.
-You can rebase the server branch onto the `master` branch without having to check it out first by running `git rebase <basebranch> <topicbranch>` -- which checks out the topic branch (in this case, `server`) for you and replays it onto the base branch (`master`):
+You can rebase the `server` branch onto the `master` branch without having to check it out first by running `git rebase <basebranch> <topicbranch>` -- which checks out the topic branch (in this case, `server`) for you and replays it onto the base branch (`master`):
 
 [source,console]
 ----
@@ -201,8 +201,8 @@ So instead of the result we see in <<_merge_rebase_work>>, we would end up with
 .Rebase on top of force-pushed rebase work.
 image::images/perils-of-rebasing-5.png[Rebase on top of force-pushed rebase work.]
 
-This only works if C4 and C4' that your partner made are almost exactly the same patch.
-Otherwise the rebase won't be able to tell that it's a duplicate and will add another C4-like patch (which will probably fail to apply cleanly, since the changes would already be at least somewhat there).
+This only works if `C4` and `C4'` that your partner made are almost exactly the same patch.
+Otherwise the `rebase` won't be able to tell that it's a duplicate and will add another C4-like patch (which will probably fail to apply cleanly, since the changes would already be at least somewhat there).
 
 You can also simplify this by running a `git pull --rebase` instead of a normal `git pull`.
 Or you could do it manually with a `git fetch` followed by a `git rebase teamone/master` in this case.
@@ -229,7 +229,7 @@ That's how it happened, and the repository should preserve that for posterity.
 
 The opposing point of view is that the commit history is the *story of how your project was made.*
 You wouldn't publish the first draft of a book, and the manual for how to maintain your software deserves careful editing.
-This is the camp that uses tools like rebase and filter-branch to tell the story in the way that's best for future readers.
+This is the camp that uses tools like `rebase` and `filter-branch` to tell the story in the way that's best for future readers.
 
 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.

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

@@ -3,7 +3,7 @@
 
 (((branches, remote)))(((references, remote)))
 Remote references are references (pointers) in your remote repositories, including branches, tags, and so on.
-You can get a full list of remote references explicitly with `git ls-remote [remote]`, or `git remote show [remote]` for remote branches as well as more information.
+You can get a full list of remote references explicitly with `git ls-remote <remote>`, or `git remote show <remote>` for remote branches as well as more information.
 Nevertheless, a more common way is to take advantage of remote-tracking branches.
 
 Remote-tracking branches are references to the state of remote branches.
@@ -31,7 +31,7 @@ If you run `git clone -o booyah` instead, then you will have `booyah/master` as
 image::images/remote-branches-1.png[Server and local repositories after cloning.]
 
 If you do some work on your local `master` branch, and, in the meantime, someone else pushes to `git.ourcompany.com` and updates its `master` branch, then your histories move forward differently.
-Also, as long as you stay out of contact with your origin server, your `origin/master` pointer doesn't move.
+Also, as long as you stay out of contact with your `origin` server, your `origin/master` pointer doesn't move.
 
 .Local and remote work can diverge
 image::images/remote-branches-2.png[Local and remote work can diverge.]
@@ -80,9 +80,9 @@ To https://github.com/schacon/simplegit
 ----
 
 This is a bit of a shortcut.
-Git automatically expands the `serverfix` branchname out to `refs/heads/serverfix:refs/heads/serverfix`, which means, ``Take my serverfix local branch and push it to update the remote's serverfix branch.''
+Git automatically expands the `serverfix` branchname out to `refs/heads/serverfix:refs/heads/serverfix`, which means, ``Take my `serverfix` local branch and push it to update the remote's `serverfix` branch''.
 We'll go over the `refs/heads/` part in detail in <<ch10-git-internals#ch10-git-internals>>, but you can generally leave it off.
-You can also do `git push origin serverfix:serverfix`, which does the same thing -- it says, ``Take my serverfix and make it the remote's serverfix.''
+You can also do `git push origin serverfix:serverfix`, which does the same thing -- it says, ``Take my serverfix and make it the remote's serverfix''.
 You can use this format to push a local branch into a remote branch that is named differently.
 If you didn't want it to be called `serverfix` on the remote, you could instead run `git push origin serverfix:awesomebranch` to push your local `serverfix` branch to the `awesomebranch` branch on the remote project.