Branching

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

@@ -51,7 +51,7 @@ If, however, you're supplying a wildcard pattern to match tag names, the use of
 
 Git supports two types of tags: _lightweight_ and _annotated_.
 
-A lightweight tag is very much like a branch that doesn't change – it's just a pointer to a specific commit.
+A lightweight tag is very much like a branch that doesn't change -- it's just a pointer to a specific commit.
 
 Annotated tags, however, are stored as full objects in the Git database.
 They're checksummed; contain the tagger name, email, and date; have a tagging message; and can be signed and verified with GNU Privacy Guard (GPG).
@@ -100,7 +100,7 @@ That shows the tagger information, the date the commit was tagged, and the annot
 
 (((tags, lightweight)))
 Another way to tag commits is with a lightweight tag.
-This is basically the commit checksum stored in a file – no other information is kept.
+This is basically the commit checksum stored in a file -- no other information is kept.
 To create a lightweight tag, don't supply any of the `-a`, `-s`, or `-m` options, just provide a tag name:
 
 [source,console]
@@ -187,7 +187,7 @@ Date:   Sun Apr 27 20:43:35 2008 -0700
 
 By default, the `git push` command doesn't transfer tags to remote servers.(((git commands, push)))
 You will have to explicitly push tags to a shared server after you have created them.
-This process is just like sharing remote branches – you can run `git push origin <tagname>`.
+This process is just like sharing remote branches -- you can run `git push origin <tagname>`.
 
 [source,console]
 ----
@@ -242,7 +242,7 @@ Previous HEAD position was 99ada87... Merge pull request #89 from schacon/append
 HEAD is now at df3f601... add atlas.json and cover image
 ----
 
-In ``detached HEAD'' state, if you make changes and then create a commit, the tag will stay the same, but your new commit won't belong to any branch and will be unreachable, except for by the exact commit hash. Thus, if you need to make changes—say you're fixing a bug on an older version, for instance—you will generally want to create a branch:
+In ``detached HEAD'' state, if you make changes and then create a commit, the tag will stay the same, but your new commit won't belong to any branch and will be unreachable, except for by the exact commit hash. Thus, if you need to make changes -- say you're fixing a bug on an older version, for instance -- you will generally want to create a branch:
 
 [source,console]
 ----

book/03-git-branching/sections/basic-branching-and-merging.asc

@@ -106,15 +106,15 @@ Fast-forward
 
 You'll notice the phrase ``fast-forward'' in that merge.
 Because the commit `C4` pointed to by the branch `hotfix` you merged in was directly ahead of the commit `C2` you're on, Git simply 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.''
+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 the fix.
 
 .`master` is fast-forwarded to `hotfix`
 image::images/basic-branching-5.png[`master` is fast-forwarded to `hotfix`.]
 
 After your super-important fix is deployed, you're ready to switch back to the work you were doing before you were interrupted.
-However, first you'll delete the `hotfix` branch, because you no longer need it – the `master` branch points at the same place.
+However, first you'll delete the `hotfix` branch, because you no longer need it -- the `master` branch points at the same place.
 You can delete it with the `-d` option to `git branch`:
 
 [source,console]

book/03-git-branching/sections/nutshell.asc

@@ -69,7 +69,7 @@ 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.
+The `git branch` command only _created_ a new branch -- it didn't switch to that branch.
 
 .HEAD pointing to a branch
 image::images/head-to-master.png[HEAD pointing to a branch.]

book/03-git-branching/sections/rebasing.asc

@@ -52,9 +52,9 @@ Now, the snapshot pointed to by `C4'` is exactly the same as the one that was po
 There is no difference in the end product of the integration, but rebasing makes for a cleaner history.
 If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.
 
-Often, you'll do this to make sure your commits apply cleanly on a remote branch – perhaps in a project to which you're trying to contribute but that you don't maintain.
+Often, you'll do this to make sure your commits apply cleanly on a remote branch -- perhaps in a project to which you're trying to contribute but that you don't maintain.
 In this case, you'd do your work in a branch and then rebase your work onto `origin/master` when you were ready to submit your patches to the main project.
-That way, the maintainer doesn't have to do any integration work – just a fast-forward or a clean apply.
+That way, the maintainer doesn't have to do any integration work -- just a fast-forward or a clean apply.
 
 Note that the snapshot pointed to by the final commit you end up with, whether it's the last of the rebased commits for a rebase or the final merge commit after a merge, is the same snapshot – it's only the history that is different.
 Rebasing replays changes from one line of work onto another in the order they were introduced, whereas merging takes the endpoints and merges them together.
@@ -98,7 +98,7 @@ $ git merge client
 image::images/interesting-rebase-3.png[Fast-forwarding your master branch to include the client branch changes.]
 
 Let's say you decide to pull in your server branch as well.
-You can rebase the server branch onto the `master` branch without having to check it out first by running `git rebase <basebranch> <topicbranch>` – which checks out the topic branch (in this case, `server`) for you and replays it onto the base branch (`master`):
+You can rebase the server branch onto the `master` branch without having to check it out first by running `git rebase <basebranch> <topicbranch>` -- which checks out the topic branch (in this case, `server`) for you and replays it onto the base branch (`master`):
 
 [source,console]
 ----

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

@@ -61,7 +61,7 @@ image::images/remote-branches-5.png[Remote tracking branch for `teamone/master`.
 
 (((pushing)))
 When you want to share a branch with the world, you need to push it up to a remote that you have write access to.
-Your local branches aren't automatically synchronized to the remotes you write to – you have to explicitly push the branches you want to share.
+Your local branches aren't automatically synchronized to the remotes you write to -- you have to explicitly push the branches you want to share.
 That way, you can use private branches for work you don't want to share, and push up only the topic branches you want to collaborate on.
 
 If you have a branch named `serverfix` that you want to work on with others, you can push it up the same way you pushed your first branch.
@@ -82,7 +82,7 @@ To https://github.com/schacon/simplegit
 This is a bit of a shortcut.
 Git automatically expands the `serverfix` branchname out to `refs/heads/serverfix:refs/heads/serverfix`, which means, ``Take my serverfix local branch and push it to update the remote's serverfix branch.''
 We'll go over the `refs/heads/` part in detail in <<_git_internals>>, but you can generally leave it off.
-You can also do `git push origin serverfix:serverfix`, which does the same thing – it says, ``Take my serverfix and make it the remote's serverfix.''
+You can also do `git push origin serverfix:serverfix`, which does the same thing -- it says, ``Take my serverfix and make it the remote's serverfix.''
 You can use this format to push a local branch into a remote branch that is named differently.
 If you didn't want it to be called `serverfix` on the remote, you could instead run `git push origin serverfix:awesomebranch` to push your local `serverfix` branch to the `awesomebranch` branch on the remote project.
 
@@ -112,7 +112,7 @@ From https://github.com/schacon/simplegit
 ----
 
 It's important to note that when you do a fetch that brings down new remote-tracking branches, you don't automatically have local, editable copies of them.
-In other words, in this case, you don't have a new `serverfix` branch – you only have an `origin/serverfix` pointer that you can't modify.
+In other words, in this case, you don't have a new `serverfix` branch -- you only have an `origin/serverfix` pointer that you can't modify.
 
 To merge this work into your current working branch, you can run `git merge origin/serverfix`.
 If you want your own `serverfix` branch that you can work on, you can base it off your remote-tracking branch:
@@ -135,7 +135,7 @@ Tracking branches are local branches that have a direct relationship to a remote
 If you're on a tracking branch and type `git pull`, Git automatically knows which server to fetch from and branch to merge into.
 
 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.
+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> <remote>/<branch>`.
 This is a common enough operation that Git provides the `--track` shorthand:
 

book/03-git-branching/sections/workflows.asc

@@ -9,8 +9,8 @@ In this section, we'll cover some common workflows that this lightweight branchi
 Because Git uses a simple three-way merge, merging from one branch into another multiple times over a long period is generally easy to do.
 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`.
+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.
@@ -41,7 +41,7 @@ But in Git it's common to create, work on, merge, and delete branches several ti
 
 You saw this in the last section with the `iss53` and `hotfix` branches you created.
 You did a few commits on them and deleted them directly after merging them into your main branch.
-This technique allows you to context-switch quickly and completely – because your work is separated into silos where all the changes in that branch have to do with that topic, it's easier to see what has happened during code review and such.
+This technique allows you to context-switch quickly and completely -- because your work is separated into silos where all the changes in that branch have to do with that topic, it's easier to see what has happened during code review and such.
 You can keep the changes there for minutes, days, or months, and merge them in when they're ready, regardless of the order in which they were created or worked on.
 
 Consider an example of doing some work (on `master`), branching off for an issue (`iss91`), working on it for a bit, branching off the second branch to try another way of handling the same thing (`iss91v2`), going back to your `master` branch and working there for a while, and then branching off there to do some work that you're not sure is a good idea (`dumbidea` branch).
@@ -60,4 +60,4 @@ image::images/topic-branches-2.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.
+When you're branching and merging, everything is being done only in your Git repository -- no server communication is happening.