Merge pull request #1362 from Morganov/fix-formatting

Use monosace font for 'master' branch name

Author: ben

C-git-commands.asc

@@ -95,7 +95,7 @@ To take a directory and turn it into a new Git repository so you can start versi
 
 We first introduce this in <<ch02-git-basics-chapter#_getting_a_repo>>, where we show creating a brand new repository to start working with.
 
-We talk briefly about how you can change the default branch from ``master'' in <<ch03-git-branching#_remote_branches>>.
+We talk briefly about how you can change the default branch name from ``master'' in <<ch03-git-branching#_remote_branches>>.
 
 We use this command to create an empty bare repository for a server in <<ch04-git-on-the-server#_bare_repo>>.
 

book/02-git-basics/sections/recording-changes.asc

@@ -33,7 +33,7 @@ nothing to commit, working directory clean
 This means you have a clean working directory; in other words, none of your tracked files are modified.
 Git also doesn't see any untracked files, or they would be listed here.
 Finally, the command tells you which branch you're on and informs you that it has not diverged from the same branch on the server.
-For now, that branch is always ``master'', which is the default; you won't worry about it here.
+For now, that branch is always `master`, which is the default; you won't worry about it here.
 <<ch03-git-branching#ch03-git-branching>> will go over branches and references in detail.
 
 Let's say you add a new file to your project, a simple `README` file.

book/02-git-basics/sections/remotes.asc

@@ -102,7 +102,7 @@ From https://github.com/paulboone/ticgit
  * [new branch]      ticgit     -> pb/ticgit
 ----
 
-Paul's master branch is now accessible locally as `pb/master` -- you can merge it into one of your branches, or you can check out a local branch at that point if you want to inspect it.
+Paul's `master` branch is now accessible locally as `pb/master` -- you can merge it into one of your branches, or you can check out a local branch at that point if you want to inspect it.
 (We'll go over what branches are and how to use them in much more detail in <<ch03-git-branching#ch03-git-branching>>.)
 
 [[_fetching_and_pulling]]
@@ -124,15 +124,15 @@ It's important to note that the `git fetch` command only downloads the data to y
 You have to merge it manually into your work when you're ready.
 
 If your current branch is set up to track a remote branch (see the next section and <<ch03-git-branching#ch03-git-branching>> for more information), you can use the `git pull` command to automatically fetch and then merge that remote branch into your current branch.(((git commands, pull)))
-This may be an easier or more comfortable workflow for you; and by default, the `git clone` command automatically sets up your local master branch to track the remote master branch (or whatever the default branch is called) on the server you cloned from.
+This may be an easier or more comfortable workflow for you; and by default, the `git clone` command automatically sets up your local `master` branch to track the remote `master` branch (or whatever the default branch is called) on the server you cloned from.
 Running `git pull` generally fetches data from the server you originally cloned from and automatically tries to merge it into the code you're currently working on.
 
 [[_pushing_remotes]]
 ==== Pushing to Your Remotes
 
 When you have your project at a point that you want to share, you have to push it upstream.
 The command for this is simple: `git push <remote> <branch>`.(((git commands, push)))
-If you want to push your master branch to your `origin` server (again, cloning generally sets up both of those names for you automatically), then you can run this to push any commits you've done back up to the server:
+If you want to push your `master` branch to your `origin` server (again, cloning generally sets up both of those names for you automatically), then you can run this to push any commits you've done back up to the server:
 
 [source,console]
 ----
@@ -167,7 +167,7 @@ $ git remote show origin
 ----
 
 It lists the URL for the remote repository as well as the tracking branch information.
-The command helpfully tells you that if you're on the master branch and you run `git pull`, it will automatically merge in the master branch on the remote after it fetches all the remote references.
+The command helpfully tells you that if you're on the `master` branch and you run `git pull`, it will automatically merge in the `master` branch on the remote after it fetches all the remote references.
 It also lists all the remote references it has pulled down.
 
 That is a simple example you're likely to encounter.

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

@@ -85,7 +85,7 @@ f30ab (HEAD -> master, testing) add feature #32 - ability to add new formats to
 98ca9 The initial commit of my project
 ----
 
-You can see the ``master'' and ``testing'' branches that are right there next to the `f30ab` commit.
+You can see the `master` and `testing` branches that are right there next to the `f30ab` commit.
 
 [[_switching_branches]]
 ==== Switching Branches

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

@@ -46,8 +46,8 @@ $ git checkout master
 $ git merge experiment
 ----
 
-.Fast-forwarding the master branch
-image::images/basic-rebase-4.png[Fast-forwarding the master branch.]
+.Fast-forwarding the `master` branch
+image::images/basic-rebase-4.png[Fast-forwarding the `master` branch.]
 
 Now, the snapshot pointed to by `C4'` is exactly the same as the one that was pointed to by `C5` in <<rebasing-merging-example,the merge example>>.
 There is no difference in the end product of the integration, but rebasing makes for a cleaner history.
@@ -95,8 +95,8 @@ $ git merge client
 ----
 
 [[rbdiag_g]]
-.Fast-forwarding your master branch to include the client branch changes
-image::images/interesting-rebase-3.png[Fast-forwarding your master branch to include the client branch changes.]
+.Fast-forwarding your `master` branch to include the client branch changes
+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`):
@@ -109,8 +109,8 @@ $ git rebase master server
 This replays your `server` work on top of your `master` work, as shown in <<rbdiag_h>>.
 
 [[rbdiag_h]]
-.Rebasing your server branch on top of your master branch
-image::images/interesting-rebase-4.png[Rebasing your server branch on top of your master branch.]
+.Rebasing your server branch on top of your `master` branch
+image::images/interesting-rebase-4.png[Rebasing your server branch on top of your `master` branch.]
 
 Then, you can fast-forward the base branch (`master`):
 

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

@@ -259,9 +259,9 @@ We'll go over this syntax in detail in <<ch07-git-tools#_commit_ranges>>.
 From the above output, we can see that there is a single commit that John has made that Jessica has not merged into her local work.
 If she merges `origin/master`, that is the single commit that will modify her local work.
 
-Now, Jessica can merge her topic work into her master branch, merge John's work (`origin/master`) into her `master` branch, and then push back to the server again.
+Now, Jessica can merge her topic work into her `master` branch, merge John's work (`origin/master`) into her `master` branch, and then push back to the server again.
 
-First (having committed all of the work on her `issue54` topic branch), Jessica switches back to her master branch in preparation for integrating all this work:
+First (having committed all of the work on her `issue54` topic branch), Jessica switches back to her `master` branch in preparation for integrating all this work:
 
 [source,console]
 ----
@@ -534,8 +534,8 @@ $ git remote add myfork <url>
 ----
 
 You then need to push your new work to this repository.
-It's easiest to push the topic branch you're working on to your forked repository, rather than merging that work into your master branch and pushing that.
-The reason is that if your work isn't accepted or is cherry-picked, you don't have to rewind your master branch (the Git `cherry-pick` operation is covered in more detail in <<ch05-distributed-git#_rebase_cherry_pick>>).
+It's easiest to push the topic branch you're working on to your forked repository, rather than merging that work into your `master` branch and pushing that.
+The reason is that if your work isn't accepted or is cherry-picked, you don't have to rewind your `master` branch (the Git `cherry-pick` operation is covered in more detail in <<ch05-distributed-git#_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.
 
 In any event, you can push your work with:

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

@@ -225,8 +225,8 @@ Now you have a topic branch that contains contributed work.
 At this point, you can determine what you'd like to do with it.
 This section revisits a couple of commands so you can see how you can use them to review exactly what you'll be introducing if you merge this into your main branch.
 
-It's often helpful to get a review of all the commits that are in this branch but that aren't in your master branch.
-You can exclude commits in the master branch by adding the `--not` option before the branch name.
+It's often helpful to get a review of all the commits that are in this branch but that aren't in your `master` branch.
+You can exclude commits in the `master` branch by adding the `--not` option before the branch name.
 This does the same thing as the `master..contrib` format that we used earlier.
 For example, if your contributor sends you two patches and you create a branch called `contrib` and applied those patches there, you can run this:
 
@@ -263,8 +263,8 @@ For example, if you've added a line in a file on the `master` branch, a direct c
 
 If `master` is a direct ancestor of your topic branch, this isn't a problem; but if the two histories have diverged, the diff will look like you're adding all the new stuff in your topic branch and removing everything unique to the `master` branch.
 
-What you really want to see are the changes added to the topic branch -- the work you'll introduce if you merge this branch with master.
-You do that by having Git compare the last commit on your topic branch with the first common ancestor it has with the master branch.
+What you really want to see are the changes added to the topic branch -- the work you'll introduce if you merge this branch with `master`.
+You do that by having Git compare the last commit on your topic branch with the first common ancestor it has with the `master` branch.
 
 Technically, you can do that by explicitly figuring out the common ancestor and then running your diff on it:
 
@@ -290,7 +290,7 @@ In the context of the `git diff` command, you can put three periods after anothe
 $ git diff master...contrib
 ----
 
-This command shows you only the work your current topic branch has introduced since its common ancestor with master.
+This command shows you only the work your current topic branch has introduced since its common ancestor with `master`.
 That is a very useful syntax to remember.
 
 ==== Integrating Contributed Work
@@ -370,8 +370,8 @@ To clearly understand this you could check out the https://github.com/git/git/bl
 ===== 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.
-When you have work in a topic branch and have determined that you want to integrate it, you move to that branch and run the rebase command to rebuild the changes on top of your current master (or `develop`, and so on) branch.
+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.
+When you have work in a topic branch and have determined that you want to integrate it, you move to that branch and run the rebase command to rebuild the changes on top of your current `master` (or `develop`, and so on) branch.
 If that works well, you can fast-forward your `master` branch, and you'll end up with a linear project history.
 
 (((git commands, cherry-pick)))
@@ -384,7 +384,7 @@ For example, suppose you have a project that looks like this:
 .Example history before a cherry-pick.
 image::images/rebasing-1.png[Example history before a cherry-pick.]
 
-If you want to pull commit `e43a6` into your master branch, you can run
+If you want to pull commit `e43a6` into your `master` branch, you can run
 
 [source,console]
 ----
@@ -517,7 +517,7 @@ $ ls *.tar.gz
 v1.6.2-rc1-20-g8c5b85c.tar.gz
 ----
 
-If someone opens that tarball, they get the latest snapshot of your project under a project directory.
+If someone opens that tarball, they get the latest snapshot of your project under a `project` directory.
 You can also create a zip archive in much the same way, but by passing the `--format=zip` option to `git archive`:
 
 [source,console]

book/07-git-tools/sections/bundling.asc

@@ -84,7 +84,7 @@ Unlike the network protocols which figure out the minimum set of data to transfe
 
 In order to do that, you'll have to calculate the difference.
 As we described in <<ch07-git-tools#_commit_ranges>>, you can specify a range of commits in a number of ways.
-To get the three commits that we have in our master branch that weren't in the branch we originally cloned, we can use something like `origin/master..master` or `master ^origin/master`.
+To get the three commits that we have in our `master` branch that weren't in the branch we originally cloned, we can use something like `origin/master..master` or `master ^origin/master`.
 You can test that with the `log` command.
 
 [source,console]
@@ -145,7 +145,7 @@ $ git bundle list-heads ../commits.bundle
 
 The `verify` sub-command will tell you the heads as well.
 The point is to see what can be pulled in, so you can use the `fetch` or `pull` commands to import commits from this bundle.
-Here we'll fetch the 'master' branch of the bundle to a branch named 'other-master' in our repository:
+Here we'll fetch the `master` branch of the bundle to a branch named `other-master` in our repository:
 
 [source,console]
 ----
@@ -154,7 +154,7 @@ From ../commits.bundle
  * [new branch]      master     -> other-master
 ----
 
-Now we can see that we have the imported commits on the 'other-master' branch as well as any commits we've done in the meantime in our own 'master' branch.
+Now we can see that we have the imported commits on the `other-master` branch as well as any commits we've done in the meantime in our own `master` branch.
 
 [source,console]
 ----

book/07-git-tools/sections/replace.asc

@@ -31,7 +31,7 @@ The second line will just be commits four and five - that will be the recent his
 
 image::images/replace1.png[]
 
-Well, creating the historical history is easy, we can just put a branch in the history and then push that branch to the master branch of a new remote repository.
+Well, creating the historical history is easy, we can just put a branch in the history and then push that branch to the `master` branch of a new remote repository.
 
 [source,console]
 ----
@@ -151,7 +151,7 @@ c1822cf first commit
 ----
 
 To combine them, you can simply call `git replace` with the commit you want to replace and then the commit you want to replace it with.
-So we want to replace the "fourth" commit in the master branch with the "fourth" commit in the `project-history/master` branch:
+So we want to replace the "fourth" commit in the `master` branch with the "fourth" commit in the `project-history/master` branch:
 
 [source,console]
 ----

book/07-git-tools/sections/rerere.asc

@@ -145,7 +145,7 @@ You can see that it "Recorded resolution for FILE".
 
 image::images/rerere2.png[]
 
-Now, let's undo that merge and then rebase it on top of our master branch instead.
+Now, let's undo that merge and then rebase it on top of our `master` branch instead.
 We can move our branch back by using `git reset` as we saw in <<ch07-git-tools#_git_reset>>.
 
 [source,console]
@@ -249,4 +249,4 @@ $ git rebase --continue
 Applying: i18n one word
 ----
 
-So, if you do a lot of re-merges, or want to keep a topic branch up to date with your master branch without a ton of merges, or you rebase often, you can turn on `rerere` to help your life out a bit.
+So, if you do a lot of re-merges, or want to keep a topic branch up to date with your `master` branch without a ton of merges, or you rebase often, you can turn on `rerere` to help your life out a bit.