Merge pull request #345 from rmzelle/branch-highlights

Highlight some branch names

Author: ben

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

@@ -63,7 +63,7 @@ All you have to do is switch back to your `master` branch.
 However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you're checking out, Git won't let you switch branches.
 It's best to have a clean working state when you switch branches.
 There are ways to get around this (namely, stashing and commit amending) that we'll cover later on, in <<_git_stashing>>.
-For now, let's assume you've committed all your changes, so you can switch back to your master branch:
+For now, let's assume you've committed all your changes, so you can switch back to your `master` branch:
 
 [source,console]
 ----
@@ -91,7 +91,7 @@ $ git commit -a -m 'fixed the broken email address'
 .Hotfix branch based on `master`
 image::images/basic-branching-4.png[Hotfix branch based on `master`.]
 
-You can run your tests, make sure the hotfix is what you want, and merge it back into your master branch to deploy to production.
+You can run your tests, make sure the hotfix is what you want, and merge it back into your `master` branch to deploy to production.
 You do this with the `git merge` command:(((git commands, merge)))
 
 [source,console]

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

@@ -32,7 +32,7 @@ image::images/commits-and-parents.png[Commits and their parents.]
 
 A branch in Git is simply a lightweight movable pointer to one of these commits.
 The default branch name in Git is `master`.
-As you start making commits, you're given a master branch that points to the last commit you made.
+As you start making commits, you're given a `master` branch that points to the last commit you made.
 Every time you commit, it moves forward automatically.
 
 [NOTE]
@@ -68,7 +68,7 @@ How does Git know what branch you're currently on?
 It keeps a special pointer called `HEAD`.
 Note that this is a lot different than the concept of `HEAD` in other VCSs you may be used to, such as Subversion or CVS.
 In Git, this is a pointer to the local branch you're currently on.
-In this case, you're still on master.
+In this case, you're still on `master`.
 The `git branch` command only _created_ a new branch – it didn't switch to that branch.
 
 .HEAD pointing to a branch
@@ -92,7 +92,7 @@ You can see the ``master'' and ``testing'' branches that are right there next to
 
 (((branches, switching)))
 To switch to an existing branch, you run the `git checkout` command.(((git commands, checkout)))
-Let's switch to the new testing branch:
+Let's switch to the new `testing` branch:
 
 [source,console]
 ----
@@ -116,8 +116,8 @@ $ git commit -a -m 'made a change'
 .The HEAD branch moves forward when a commit is made
 image::images/advance-testing.png[The HEAD branch moves forward when a commit is made.]
 
-This is interesting, because now your testing branch has moved forward, but your master branch still points to the commit you were on when you ran `git checkout` to switch branches.
-Let's switch back to the master branch:
+This is interesting, because now your `testing` branch has moved forward, but your `master` branch still points to the commit you were on when you ran `git checkout` to switch branches.
+Let's switch back to the `master` branch:
 
 [source,console]
 ----
@@ -128,9 +128,9 @@ $ git checkout master
 image::images/checkout-master.png[HEAD moves when you checkout.]
 
 That command did two things.
-It moved the HEAD pointer back to point to the master branch, and it reverted the files in your working directory back to the snapshot that master points to.
+It moved the HEAD pointer back to point to the `master` branch, and it reverted the files in your working directory back to the snapshot that `master` points to.
 This also means the changes you make from this point forward will diverge from an older version of the project.
-It essentially rewinds the work you've done in your testing branch so you can go in a different direction.
+It essentially rewinds the work you've done in your `testing` branch so you can go in a different direction.
 
 [NOTE]
 .Switching branches changes files in your working directory

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

@@ -37,7 +37,7 @@ It works by going to the common ancestor of the two branches (the one you're on
 .Rebasing the change introduced in `C4` onto `C3`
 image::images/basic-rebase-3.png[Rebasing the change introduced in `C4` onto `C3`.]
 
-At this point, you can go back to the master branch and do a fast-forward merge.
+At this point, you can go back to the `master` branch and do a fast-forward merge.
 
 [source,console]
 ----
@@ -72,7 +72,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]
 ----
@@ -85,7 +85,7 @@ It's a bit complex, but the result is pretty cool.
 .Rebasing a topic branch off another topic branch
 image::images/interesting-rebase-2.png[Rebasing a topic branch off another topic branch.]
 
-Now you can fast-forward your master branch (see <<rbdiag_g>>):
+Now you can fast-forward your `master` branch (see <<rbdiag_g>>):
 
 [source,console]
 ----
@@ -98,7 +98,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]
 ----

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

@@ -30,7 +30,7 @@ If you run `git clone -o booyah` instead, then you will have `booyah/master` as
 .Server and local repositories after cloning
 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.
+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.
 
 .Local and remote work can diverge

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

@@ -44,7 +44,7 @@ You did a few commits on them and deleted them directly after merging them into
 This technique allows you to context-switch quickly and completely – because your work is separated into silos where all the changes in that branch have to do with that topic, it's easier to see what has happened during code review and such.
 You can keep the changes there for minutes, days, or months, and merge them in when they're ready, regardless of the order in which they were created or worked on.
 
-Consider an example of doing some work (on `master`), branching off for an issue (`iss91`), working on it for a bit, branching off the second branch to try another way of handling the same thing (`iss91v2`), going back to your master branch and working there for a while, and then branching off there to do some work that you're not sure is a good idea (`dumbidea` branch).
+Consider an example of doing some work (on `master`), branching off for an issue (`iss91`), working on it for a bit, branching off the second branch to try another way of handling the same thing (`iss91v2`), going back to your `master` branch and working there for a while, and then branching off there to do some work that you're not sure is a good idea (`dumbidea` branch).
 Your commit history will look something like this:
 
 .Multiple topic branches