various smaller changes and syntax

schacon · schacon · commit 4fc35b7b82b5 · 2014-06-09T15:41:09.000-07:00
diff --git a/book/03-git-branching/1-git-branching.asc b/book/03-git-branching/1-git-branching.asc
@@ -493,7 +493,6 @@ Conflicts:
 
 You can modify that message with details about how you resolved the merge if you think it would be helpful to others looking at this merge in the future – why you did what you did, if it's not obvious.
 
-
 === Branch Management
 
 Now that you've created, merged, and deleted some branches, let's look at some branch-management tools that will come in handy when you begin using branches all the time.
@@ -509,7 +508,7 @@ $ git branch
   testing
 ----
 
-Notice the `*` character that prefixes the `master` branch: it indicates the branch that you currently have checked out.
+Notice the `*` character that prefixes the `master` branch: it indicates the branch that you currently have checked out (i.e., the branch that `HEAD` points to).
 This means that if you commit at this point, the `master` branch will be moved forward with your new work.
 To see the last commit on each branch, you can run `git branch -v`:
 
@@ -565,7 +564,7 @@ Because Git uses a simple three-way merge, merging from one branch into another
 This means you can have several branches that are always open and that you use for different stages of your development cycle; you can merge regularly from some of them into others.
 
 Many Git developers have a workflow that embraces this approach, such as having only code that is entirely stable in their `master` branch – possibly only code that has been or will be released.
-They have another parallel branch named develop or next that they work from or use to test stability – it isn't necessarily always stable, but whenever it gets to a stable state, it can be merged into `master`.
+They have another parallel branch named `develop` or `next` that they work from or use to test stability – it isn't necessarily always stable, but whenever it gets to a stable state, it can be merged into `master`.
 It's used to pull in topic branches (short-lived branches, like your earlier `iss53` branch) when they're ready, to make sure they pass all the tests and don't introduce bugs.
 
 In reality, we're talking about pointers moving up the line of commits you're making.
@@ -610,13 +609,15 @@ Your history then looks like this:
 .History after merging `dumbidea` and `iss91v2`
 image::images/18333fig0321-tn.png[History after merging `dumbidea` and `iss91v2`.]
 
+We will go into more detail about the various possible workflows for your Git project in <<_distributed_git>>, so before you decide which branching scheme your next project will use, be sure to read that chapter.
+
 It's important to remember when you're doing all this that these branches are completely local.
 When you're branching and merging, everything is being done only in your Git repository – no server communication is happening.
 
 === Remote Branches
 
-Remote branches are references to the state of branches on your remote repositories.
-They're local branches that you can't move; they're moved automatically whenever you do any network communication.
+Remote branches are references (pointers) to the state of branches in your remote repositories.
+They're local branches that you can't move; they're moved automatically for you whenever you do any network communication.
 Remote branches act as bookmarks to remind you where the branches on your remote repositories were the last time you connected to them.
 
 They take the form `(remote)/(branch)`.
@@ -625,8 +626,8 @@ If you were working on an issue with a partner and they pushed up an `iss53` bra
 
 This may be a bit confusing, so let's look at an example.
 Let's say you have a Git server on your network at `git.ourcompany.com`.
-If you clone from this, Git automatically names it `origin` for you, pulls down all its data, creates a pointer to where its `master` branch is, and names it `origin/master` locally; and you can't move it.
-Git also gives you your own `master` branch starting at the same place as origin's `master` branch, so you have something to work from.
+If you clone from this, Git's `clone` command automatically names it `origin` for you, pulls down all its data, creates a pointer to where its `master` branch is, and names it `origin/master` locally.
+Git also gives you your own local `master` branch starting at the same place as origin's `master` branch, so you have something to work from.
 
 [NOTE]
 .``origin'' is not special
@@ -637,14 +638,14 @@ Just like the branch name ``master'' does not have any special meaning in Git, n
 .Server and local repositories after cloning
 image::images/18333fig0322-tn.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
 image::images/18333fig0323-tn.png[Local and remote work can diverge.]
 
 To synchronize your work, you run a `git fetch origin` command.
-This command looks up which server origin is (in this case, it's `git.ourcompany.com`), fetches any data from it that you don't yet have, and updates your local database, moving your `origin/master` pointer to its new, more up-to-date position.
+This command looks up which server ``origin'' is (in this case, it's `git.ourcompany.com`), fetches any data from it that you don't yet have, and updates your local database, moving your `origin/master` pointer to its new, more up-to-date position.
 
 .`git fetch` updates your remote references
 image::images/18333fig0324-tn.png[`git fetch` updates your remote references.]
@@ -680,7 +681,7 @@ Delta compression using up to 8 threads.
 Compressing objects: 100% (15/15), done.
 Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done.
 Total 24 (delta 2), reused 0 (delta 0)
-To git@github.com:schacon/simplegit.git
+To https://github.com/schacon/simplegit
  * [new branch]      serverfix -> serverfix
 ----
 
@@ -700,7 +701,7 @@ remote: Counting objects: 7, done.
 remote: Compressing objects: 100% (2/2), done.
 remote: Total 3 (delta 0), reused 3 (delta 0)
 Unpacking objects: 100% (3/3), done.
-From git@github.com:schacon/simplegit
+From https://github.com/schacon/simplegit
  * [new branch]      serverfix    -> origin/serverfix
 ----
 
@@ -719,7 +720,7 @@ Switched to a new branch 'serverfix'
 
 This gives you a local branch that you can work on that starts where `origin/serverfix` is.
 
-==== Tracking/Upstream Branches
+==== Tracking Branches
 
 Checking out a local branch from a remote branch automatically creates what is called a ``tracking branch'' (or sometimes an ``upstream branch'').
 Tracking branches are local branches that have a direct relationship to a remote branch.
@@ -748,7 +749,8 @@ Branch sf set up to track remote branch serverfix from origin.
 Switched to a new branch 'sf'
 ----
 
-Now, your local branch sf will automatically push to and pull from origin/serverfix.
+Now, your local branch sf will automatically push to and pull from `origin/serverfix`.
+
 If you already have a local branch and want to set it to a remote branch you just pulled down, or want to change the upstream branch you're tracking, you can use the `-u` or `--set-upstream-to` option to `git branch` to explicitly set it at any time.
 
 [source,shell]
