Trim unnecessary "(see figure X)"s

Author: ben

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

@@ -44,15 +44,13 @@ What happens if you create a new branch? Well, doing so creates a new pointer fo
 $ git branch testing
 ----
 
-This creates a new pointer at the same commit you’re currently on (see <<history_diagram_a>>).
+This creates a new pointer at the same commit you’re currently on.
 
-[[history_diagram_a]]
 .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.
 
-[[history_diagram_b]]
 .HEAD file pointing to the branch you’re on
 image::images/18333fig0305-tn.png[HEAD file pointing to the branch you’re on.]
 
@@ -63,9 +61,8 @@ 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.
 
-[[history_diagram_c]]
 .HEAD points to another branch when you switch branches
 image::images/18333fig0306-tn.png[HEAD points to another branch when you switch branches.]
 
@@ -134,9 +131,8 @@ At this stage, you’ll receive a call that another issue is critical and you ne
 
 ==== Basic Branching
 
-First, let’s say you’re working on your project and have a couple of commits already (see <<branch_diagram_a>>).
+First, let’s say you’re working on your project and have a couple of commits already.
 
-[[branch_diagram_a]]
 .A short and simple commit history
 image::images/18333fig0310-tn.png[A short and simple commit history.]
 
@@ -216,9 +212,8 @@ README |    1 -
 
 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 (see <<branch_diagram_e>>).
+Your change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy your change.
 
-[[branch_diagram_e]]
 .Your master branch points to the same place as your hotfix branch after the merge
 image::images/18333fig0314-tn.png[Your master branch points to the same place as your hotfix branch after the merge.]
 
@@ -448,13 +443,12 @@ Because Git uses a simple three-way merge, merging from one branch into another
 
 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`. 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. The stable branches are farther down the line in your commit history, and the bleeding-edge branches are farther up the history (see <<lrbranch_a>>).
+In reality, we’re talking about pointers moving up the line of commits you’re making. The stable branches are farther down the line in your commit history, and the bleeding-edge branches are farther up the history.
 
-[[lrbranch_a]]
 .More stable branches are generally farther down the commit history
 image::images/18333fig0318-tn.png[More stable branches are generally farther down the commit history.]
 
-It’s generally easier to think about them as work silos, where sets of commits graduate to a more stable silo when they’re fully tested (see <<lrbranch_b>>).
+It’s generally easier to think about them as work silos, where sets of commits graduate to a more stable silo when they’re fully tested.
 
 [[lrbranch_b]]
 .It may be helpful to think of your branches as silos
@@ -489,33 +483,28 @@ Remote branches are references to the state of branches on your remote repositor
 
 They take the form `(remote)/(branch)`. For instance, if you wanted to see what the `master` branch on your `origin` remote looked like as of the last time you communicated with it, you would check the `origin/master` branch. If you were working on an issue with a partner and they pushed up an `iss53` branch, you might have your own local `iss53` branch; but the branch on the server would point to the commit at `origin/iss53`.
 
-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 (see <<rembranch_a>>).
+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.
 
-[[rembranch_a]]
 .A Git clone gives you your own master branch and origin/master pointing to origin’s master branch
 image::images/18333fig0322-tn.png[A Git clone gives you your own master branch and origin/master pointing to origin’s master branch.]
 
-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 (see <<rembranch_b>>).
+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.
 
-[[rembranch_b]]
 .Working locally and having someone push to your remote server makes each history move forward differently
 image::images/18333fig0323-tn.png[Working locally and having someone push to your remote server makes each history move forward differently.]
 
-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 (see <<rembranch_c>>).
+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.
 
-[[rembranch_c]]
 .The git fetch command updates your remote references
 image::images/18333fig0324-tn.png[The git fetch command updates your remote references.]
 
-To demonstrate having multiple remote servers and what remote branches for those remote projects look like, let’s assume you have another internal Git server that is used only for development by one of your sprint teams. This server is at `git.team1.ourcompany.com`. You can add it as a new remote reference to the project you’re currently working on by running the `git remote add` command as we covered in <<_git_basics_chapter>>. Name this remote `teamone`, which will be your shortname for that whole URL (see <<rembranch_d>>).
+To demonstrate having multiple remote servers and what remote branches for those remote projects look like, let’s assume you have another internal Git server that is used only for development by one of your sprint teams. This server is at `git.team1.ourcompany.com`. You can add it as a new remote reference to the project you’re currently working on by running the `git remote add` command as we covered in <<_git_basics_chapter>>. Name this remote `teamone`, which will be your shortname for that whole URL.
 
-[[rembranch_d]]
 .Adding another server as a remote
 image::images/18333fig0325-tn.png[Adding another server as a remote.]
 
-Now, you can run `git fetch teamone` to fetch everything the remote `teamone` server has that you don’t have yet. Because that server is a subset of the data your `origin` server has right now, Git fetches no data but sets a remote branch called `teamone/master` to point to the commit that `teamone` has as its `master` branch (see <<rembranch_e>>).
+Now, you can run `git fetch teamone` to fetch everything the remote `teamone` server has that you don’t have yet. Because that server is a subset of the data your `origin` server has right now, Git fetches no data but sets a remote branch called `teamone/master` to point to the commit that `teamone` has as its `master` branch.
 
-[[rembranch_e]]
 .You get a reference to teamone’s master branch position locally
 image::images/18333fig0326-tn.png[You get a reference to teamone’s master branch position locally.]
 
@@ -637,9 +626,8 @@ It works by going to the common ancestor of the two branches (the one you’re o
 .Rebasing the change introduced in C3 onto C4
 image::images/18333fig0329-tn.png[Rebasing the change introduced in C3 onto C4.]
 
-At this point, you can go back to the master branch and do a fast-forward merge (see <<rbdiag_d>>).
+At this point, you can go back to the master branch and do a fast-forward merge.
 
-[[rbdiag_d]]
 .Fast-forwarding the master branch
 image::images/18333fig0330-tn.png[Fast-forwarding the master branch.]
 
@@ -742,9 +730,8 @@ Next, the person who pushed the merged work decides to go back and rebase their
 .Someone pushes rebased commits, abandoning commits you’ve based your work on
 image::images/18333fig0338-tn.png[Someone pushes rebased commits, abandoning commits you’ve based your work on.]
 
-At this point, you have to merge this work in again, even though you’ve already done so. Rebasing changes the SHA-1 hashes of these commits so to Git they look like new commits, when in fact you already have the C4 work in your history (see <<rbdiag_l>>).
+At this point, you have to merge this work in again, even though you’ve already done so. Rebasing changes the SHA-1 hashes of these commits so to Git they look like new commits, when in fact you already have the C4 work in your history.
 
-[[rbdiag_l]]
 .You merge in the same work again into a new merge commit
 image::images/18333fig0339-tn.png[You merge in the same work again into a new merge commit.]