Standardize on <remote>, not <remotename> or <remote-name> for examples

book/02-git-basics/sections/remotes.asc

@@ -104,7 +104,7 @@ As you just saw, to get data from your remote projects, you can run:(((git comma
 
 [source,console]
 ----
-$ git fetch <remote-name>
+$ git fetch <remote>
 ----
 
 The command goes out to that remote project and pulls down all the data from that remote project that you don't have yet.
@@ -123,7 +123,7 @@ Running `git pull` generally fetches data from the server you originally cloned
 ==== Pushing to Your Remotes
 
 When you have your project at a point that you want to share, you have to push it upstream.
-The command for this is simple: `git push <remote-name> <branch-name>`.(((git commands, push)))
+The command for this is simple: `git push <remote> <branch>`.(((git commands, push)))
 If you want to push your master branch to your `origin` server (again, cloning generally sets up both of those names for you automatically), then you can run this to push any commits you've done back up to the server:
 
 [source,console]
@@ -139,7 +139,7 @@ See <<_git_branching>> for more detailed information on how to push to remote se
 [[_inspecting_remote]]
 ==== Inspecting a Remote
 
-If you want to see more information about a particular remote, you can use the `git remote show <remote-name>` command.(((git commands, remote)))
+If you want to see more information about a particular remote, you can use the `git remote show <remote>` command.(((git commands, remote)))
 If you run this command with a particular shortname, such as `origin`, you get something like this:
 
 [source,console]

book/02-git-basics/sections/tagging.asc

@@ -225,7 +225,7 @@ state without impacting any branches by performing another checkout.
 If you want to create a new branch to retain commits you create, you may
 do so (now or later) by using -b with the checkout command again. Example:
 
-  git checkout -b <new-branch-name>
+  git checkout -b <new-branch>
 
 HEAD is now at 99ada87... Merge pull request #89 from schacon/appendix-final
 

book/03-git-branching/sections/remote-branches.asc

@@ -136,7 +136,7 @@ If you're on a tracking branch and type `git pull`, Git automatically knows whic
 
 When you clone a repository, it generally automatically creates a `master` branch that tracks `origin/master`.
 However, you can set up other tracking branches if you wish – ones that track branches on other remotes, or don't track the `master` branch.
-The simple case is the example you just saw, running `git checkout -b <branch> <remotename>/<branch>`.
+The simple case is the example you just saw, running `git checkout -b <branch> <remote>/<branch>`.
 This is a common enough operation that Git provides the `--track` shorthand:
 
 [source,console]

book/07-git-tools/sections/stashing-cleaning.asc

@@ -189,7 +189,7 @@ Saved working directory and index state WIP on master: 1b65b17 added the index f
 
 If you stash some work, leave it there for a while, and continue on the branch from which you stashed the work, you may have a problem reapplying the work.
 If the apply tries to modify a file that you’ve since modified, you’ll get a merge conflict and will have to try to resolve it.
-If you want an easier way to test the stashed changes again, you can run `git stash branch <branch-name>`, which creates a new branch for you with the given `branch-name`, checks out the commit you were on when you stashed your work, reapplies your work there, and then drops the stash if it applies successfully:
+If you want an easier way to test the stashed changes again, you can run `git stash branch <branch>`, which creates a new branch for you with your selected branch name, checks out the commit you were on when you stashed your work, reapplies your work there, and then drops the stash if it applies successfully:
 
 [source,console]
 ----

book/09-git-and-other-scms/sections/client-svn.asc

@@ -341,7 +341,7 @@ However, you can create and commit to branches in Subversion using `git svn`.
 
 ===== Creating a New SVN Branch
 
-To create a new branch in Subversion, you run `git svn branch [branchname]`:
+To create a new branch in Subversion, you run `git svn branch [new-branch]`:
 
 [source,console]
 ----

book/10-git-internals/sections/refs.asc

@@ -63,12 +63,12 @@ Now, your Git database conceptually looks something like this:
 .Git directory objects with branch head references included.
 image::images/data-model-4.png[Git directory objects with branch head references included.]
 
-When you run commands like `git branch <branchname>`, Git basically runs that `update-ref` command to add the SHA-1 of the last commit of the branch you're on into whatever new reference you want to create.
+When you run commands like `git branch <branch>`, Git basically runs that `update-ref` command to add the SHA-1 of the last commit of the branch you're on into whatever new reference you want to create.
 
 [[_the_head]]
 ==== The HEAD
 
-The question now is, when you run `git branch <branchname>`, how does Git know the SHA-1 of the last commit?
+The question now is, when you run `git branch <branch>`, how does Git know the SHA-1 of the last commit?
 The answer is the HEAD file.
 
 The HEAD file is a symbolic reference to the branch you're currently on.