Edits, part I

Author: ben

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

@@ -32,7 +32,7 @@ If you make some changes and commit again, the next commit stores a pointer to t
 .Git object data for multiple commits
 image::images/18333fig0302-tn.png[Git object data for multiple commits.]
 
-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 initially make commits, you’re given a master branch that points to the last commit you made. Every time you commit, it moves forward automatically.
+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.
 
 .Branch pointing into the commit data’s history
 image::images/18333fig0303-tn.png[Branch pointing into the commit data’s history.]
@@ -50,7 +50,7 @@ This creates a new pointer at the same commit you’re currently on (see <<histo
 .Multiple branches pointing into the commit’s data history
 image::images/18333fig0304-tn.png[Multiple branches pointing into the commit’s data history.]
 
-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. The git branch command only created a new branch – it didn’t switch to that branch (see <<history_diagram_b>>).
+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. The `git branch` command only _created_ a new branch – it didn’t switch to that branch (see <<history_diagram_b>>).
 
 [[history_diagram_b]]
 .HEAD file pointing to the branch you’re on
@@ -63,7 +63,7 @@ To switch to an existing branch, you run the `git checkout` command. Let’s swi
 $ git checkout testing
 ----
 
-This moves HEAD to point to the testing branch (see <<history_diagram_c>>).
+This moves `HEAD` to point to the `testing` branch (see <<history_diagram_c>>).
 
 [[history_diagram_c]]
 .HEAD points to another branch when you switch branches
@@ -96,7 +96,7 @@ $ git checkout master
 .HEAD moves to another branch on a checkout
 image::images/18333fig0308-tn.png[HEAD moves to another branch on a 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. 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 temporarily so you can go in a different direction.
+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. 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.
 
 Let’s make a few changes and commit again:
 
@@ -106,14 +106,14 @@ $ vim test.rb
 $ git commit -a -m 'made other changes'
 ----
 
-Now your project history has diverged (see Figure 3-9). You created and switched to a branch, did some work on it, and then switched back to your main branch and did other work. Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you’re ready. And you did all that with simple `branch` and `checkout` commands.
+Now your project history has diverged (see Figure 3-9). You created and switched to a branch, did some work on it, and then switched back to your main branch and did other work. Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you’re ready. And you did all that with simple `branch`, `checkout`, and `commit` commands.
 
 .The branch histories have diverged
 image::images/18333fig0309-tn.png[The branch histories have diverged.]
 
 Because a branch in Git is in actuality a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline).
 
-This is in sharp contrast to the way most VCS tools branch, which involves copying all of the project’s files into a second directory. This can take several seconds or even minutes, depending on the size of the project, whereas in Git the process is always instantaneous. Also, because we’re recording the parents when we commit, finding a proper merge base for merging is automatically done for us and is generally very easy to do. These features help encourage developers to create and use branches often.
+This is in sharp contrast to the way most older VCS tools branch, which involves copying all of the project’s files into a second directory. This can take several seconds or even minutes, depending on the size of the project, whereas in Git the process is always instantaneous. Also, because we’re recording the parents when we commit, finding a proper merge base for merging is automatically done for us and is generally very easy to do. These features help encourage developers to create and use branches often.
 
 Let’s see why you should do so.