nutshell.asc: minor tweaks for fonts/wording/emphasis

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

@@ -3,13 +3,13 @@
 
 To really understand the way Git does branching, we need to take a step back and examine how Git stores its data.
 
-As you may remember from <<ch01-getting-started#ch01-getting-started>>, Git doesn't store data as a series of changesets or differences, but instead as a series of snapshots.
+As you may remember from <<ch01-getting-started#ch01-getting-started>>, Git doesn't store data as a series of changesets or differences, but instead as a series of _snapshots_.
 
 When you make a commit, Git stores a commit object that contains a pointer to the snapshot of the content you staged.
-This object also contains the author's name and email, the message that you typed, and pointers to the commit or commits that directly came before this commit (its parent or parents): zero parents for the initial commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches.
+This object also contains the author's name and email address, the message that you typed, and pointers to the commit or commits that directly came before this commit (its parent or parents): zero parents for the initial commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches.
 
 To visualize this, let's assume that you have a directory containing three files, and you stage them all and commit.
-Staging the files computes a checksum for each one (the SHA-1 hash we mentioned in <<ch01-getting-started#ch01-getting-started>>), stores that version of the file in the Git repository (Git refers to them as blobs), and adds that checksum to the staging area:
+Staging the files computes a checksum for each one (the SHA-1 hash we mentioned in <<ch01-getting-started#ch01-getting-started>>), stores that version of the file in the Git repository (Git refers to them as _blobs_), and adds that checksum to the staging area:
 
 [source,console]
 ----
@@ -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: one blob for the contents of each of your 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.]
@@ -33,7 +33,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.
-Every time you commit, it moves forward automatically.
+Every time you commit, the `master` branch pointer moves forward automatically.
 
 [NOTE]
 ====
@@ -51,7 +51,7 @@ image::images/branch-and-history.png[A branch and its commit history.]
 (((branches, creating)))
 What happens if you create a new branch?
 Well, doing so creates a new pointer for you to move around.
-Let's say you create a new branch called testing.
+Let's say you want to create a new branch called `testing`.
 You do this with the `git branch` command:(((git commands, branch)))
 
 [source,console]