Edits part II

Author: ben

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

@@ -136,7 +136,7 @@ First, let’s say you’re working on your project and have a couple of commits
 .A short and simple commit history
 image::images/18333fig0310-tn.png[A short and simple commit history.]
 
-You’ve decided that you’re going to work on issue #53 in whatever issue-tracking system your company uses. To be clear, Git isn’t tied into any particular issue-tracking system; but because issue #53 is a focused topic that you want to work on, you’ll create a new branch in which to work. To create a branch and switch to it at the same time, you can run the `git checkout` command with the `-b` switch:
+You’ve decided that you’re going to work on issue #53 in whatever issue-tracking system your company uses. To create a branch and switch to it at the same time, you can run the `git checkout` command with the `-b` switch:
 
 [source,shell]
 ----
@@ -158,7 +158,7 @@ $ git checkout iss53
 .Creating a new branch pointer
 image::images/18333fig0311-tn.png[Creating a new branch pointer.]
 
-You work on your web site and do some commits. Doing so moves the `iss53` branch forward, because you have it checked out (that is, your HEAD is pointing to it; see <<branch_diagram_c>>):
+You work on your web site and do some commits. Doing so moves the `iss53` branch forward, because you have it checked out (that is, your `HEAD` is pointing to it; see <<branch_diagram_c>>):
 
 [source,shell]
 ----
@@ -172,12 +172,12 @@ image::images/18333fig0312-tn.png[The iss53 branch has moved forward with your w
 
 Now you get the call that there is an issue with the web site, and you need to fix it immediately. With Git, you don’t have to deploy your fix along with the `iss53` changes you’ve made, and you don’t have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. 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. For now, you’ve committed all your changes, so you can 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. For now, let's assume you’ve committed all your changes, so you can switch back to your master branch:
 
 [source,shell]
 ----
 $ git checkout master
-Switched to branch "master"
+Switched to branch 'master'
 ----
 
 At this point, your project working directory is exactly the way it was before you started working on issue #53, and you can concentrate on your hotfix. This is an important point to remember: Git resets your working directory to look like the snapshot of the commit that the branch you check out points to. It adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it.
@@ -187,11 +187,11 @@ Next, you have a hotfix to make. Let’s create a hotfix branch on which to work
 [source,shell]
 ----
 $ git checkout -b 'hotfix'
-Switched to a new branch "hotfix"
+Switched to a new branch 'hotfix'
 $ vim index.html
 $ git commit -a -m 'fixed the broken email address'
-[hotfix]: created 3a0874c: "fixed the broken email address"
-1 files changed, 0 insertions(+), 1 deletions(-)
+[hotfix 1fb7853] fixed the broken email address
+ 1 file changed, 2 insertions(+)
 ----
 
 [[branch_diagram_d]]
@@ -205,12 +205,12 @@ You can run your tests, make sure the hotfix is what you want, and merge it back
 $ git checkout master
 $ git merge hotfix
 Updating f42c576..3a0874c
-Fast forward
-README |    1 -
-1 files changed, 0 insertions(+), 1 deletions(-)
+Fast-forward
+ index.html | 2 ++
+ 1 file changed, 2 insertions(+)
 ----
 
-You’ll notice the phrase ``Fast forward'' in that merge. Because the commit pointed to by the branch you merged in was directly upstream of the commit you’re on, Git moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together – this is called a ``fast forward''.
+You’ll notice the phrase ``Fast-forward'' in that merge. Because the commit pointed to by the branch you merged in was directly upstream of the commit you’re on, Git moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together – this is called a ``fast-forward''.
 
 Your change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy your change.
 
@@ -233,8 +233,8 @@ $ git checkout iss53
 Switched to branch "iss53"
 $ vim index.html
 $ git commit -a -m 'finished the new footer [issue 53]'
-[iss53]: created ad82d7a: "finished the new footer [issue 53]"
-1 files changed, 1 insertions(+), 0 deletions(-)
+[iss53 ad82d7a] finished the new footer [issue 53]
+1 file changed, 1 insertion(+)
 ----
 
 [[branch_diagram_f]]
@@ -250,10 +250,11 @@ Suppose you’ve decided that your issue #53 work is complete and ready to be me
 [source,shell]
 ----
 $ git checkout master
+Switched to branch 'master'
 $ git merge iss53
-Merge made by recursive.
+Merge made by the 'recursive' strategy.
 README |    1 +
-1 files changed, 1 insertions(+), 0 deletions(-)
+1 file changed, 1 insertion(+)
 ----
 
 This looks a bit different than the `hotfix` merge you did earlier. In this case, your development history has diverged from some older point. Because the commit on the branch you’re on isn’t a direct ancestor of the branch you’re merging in, Git has to do some work. In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two. <<merge_diagram_a>> highlights the three snapshots that Git uses to do its merge in this case.
@@ -262,15 +263,15 @@ This looks a bit different than the `hotfix` merge you did earlier. In this case
 .Git automatically identifies the best common-ancestor merge base for branch merging
 image::images/18333fig0316-tn.png[Git automatically identifies the best common-ancestor merge base for branch merging.]
 
-Instead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it (see <<merge_diagram_b>>). This is referred to as a merge commit and is special in that it has more than one parent.
+Instead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it (see <<merge_diagram_b>>). This is referred to as a merge commit, and is special in that it has more than one parent.
 
-It’s worth pointing out that Git determines the best common ancestor to use for its merge base; this is different than CVS or Subversion (before version 1.5), where the developer doing the merge has to figure out the best merge base for themselves. This makes merging a heck of a lot easier in Git than in these other systems.
+It’s worth pointing out that Git determines the best common ancestor to use for its merge base; this is different than older tools like CVS or Subversion (before version 1.5), where the developer doing the merge had to figure out the best merge base for themselves. This makes merging a heck of a lot easier in Git than in these other systems.
 
 [[merge_diagram_b]]
 .Git automatically creates a new commit object that contains the merged work
 image::images/18333fig0317-tn.png[Git automatically creates a new commit object that contains the merged work.]
 
-Now that your work is merged in, you have no further need for the `iss53` branch. You can delete it and then manually close the ticket in your ticket-tracking system:
+Now that your work is merged in, you have no further need for the `iss53` branch. You can delete it and then close the ticket in your ticket-tracking system:
 
 [source,shell]
 ----