Fix a bunch of typos, mostly punctuation.

Some changes in word choice.

src/levels/rampup/cherryPick.js

@@ -25,7 +25,7 @@ exports.level = {
               "",
               "So far we've covered the basics of git -- committing, branching, and moving around in the source tree. Just these concepts are enough to leverage 90% of the power of git repositories and cover the main needs of developers.",
               "",
-              "That remaining 10%, however, can be quite useful during complex workflows (or when you've gotten yourself into a bind). The next concept we're going to cover is \"moving work around\" -- in other words, its a way for developers to say \"I want this work here and that work here\" in precise, eloquent, flexible ways.",
+              "That remaining 10%, however, can be quite useful during complex workflows (or when you've gotten yourself into a bind). The next concept we're going to cover is \"moving work around\" -- in other words, it's a way for developers to say \"I want this work here and that work there\" in precise, eloquent, flexible ways.",
               "",
               "This may seem like a lot, but it's a simple concept."
             ]

src/levels/rampup/interactiveRebase.js

@@ -51,9 +51,9 @@ exports.level = {
               "",
               "* You can reorder commits simply by changing their order in the UI (in our window this means dragging and dropping with the mouse).",
               "* You can choose to completely omit some commits. This is designated by `pick` -- toggling `pick` off means you want to drop the commit.",
-              "* Lastly, you can squash commits. Unfortunately our levels don't support this for a few logistical reasons, so I\"ll skip over the details of this. Long story short though -- it allows you to combine commits.",
+              "* Lastly, you can squash commits. Unfortunately our levels don't support this for a few logistical reasons, so I'll skip over the details of this. Long story short, though -- it allows you to combine commits.",
               "",
-              "Great! Lets see an example"
+              "Great! Let's see an example."
             ]
           }
         },

src/levels/rebase/manyRebases.js

@@ -32,7 +32,7 @@ exports.level = {
               "",
               "Man, we have a lot of branches going on here! Let's rebase all the work from these branches onto master.",
               "",
-              "Upper management is making this a bit trickier though -- they want the commits to all be in sequential order. So this means that our final tree should have `C7'` at the bottom, `C6'` above that, etc etc, etc all in order.",
+              "Upper management is making this a bit trickier though -- they want the commits to all be in sequential order. So this means that our final tree should have `C7'` at the bottom, `C6'` above that, and so on, all in order.",
               "",
               "If you mess up along the way, feel free to use `reset` to start over again. Be sure to check out our solution and see if you can do it in fewer commands!"
             ]

src/levels/remote/fetch.js

@@ -19,7 +19,7 @@ exports.level = {
             "markdowns": [
               "## Git Fetch",
               "",
-              "Working with git remotes really just boils down to transferring data _to_ and _from_ other repositories. As long as we can send commits back and forth, we can share any type of update that is tracked by git (and thus share work, new files, new ideas, love letters, etc etc).",
+              "Working with git remotes really just boils down to transferring data _to_ and _from_ other repositories. As long as we can send commits back and forth, we can share any type of update that is tracked by git (and thus share work, new files, new ideas, love letters, etc.).",
               "",
               "In this lesson we will learn how to fetch data _from_ a remote repository -- the command for this is conveniently named `git fetch`.",
               "",
@@ -53,7 +53,7 @@ exports.level = {
               "",
               "`git fetch` essentially brings our _local_ representation of the remote repository into synchronization with what the _actual_ remote repository looks like (right now).",
               "",
-              "If you remember from the previous lesson, we said that remote branches reflect the state of the remote repositories _since_ you last talked to those remotes. `git fetch` is the way you talk to these remotes! Hopefully the connection between remote branches and `git fetch` is apparent now",
+              "If you remember from the previous lesson, we said that remote branches reflect the state of the remote repositories _since_ you last talked to those remotes. `git fetch` is the way you talk to these remotes! Hopefully the connection between remote branches and `git fetch` is apparent now.",
               "",
               "`git fetch` usually talks to the remote repository through the Internet (via a protocol like `http://` or `git://`).",
               ""

src/levels/remote/fetchArgs.js

@@ -39,7 +39,7 @@ exports.level = {
               "",
               "Git will go to the `foo` branch on the remote, grab all the commits that aren't present locally, and then plop them down onto the `o/foo` branch locally.",
               "",
-              "Let's see this in action (just as a refresher)"
+              "Let's see this in action (just as a refresher)."
             ]
           }
         },
@@ -77,7 +77,7 @@ exports.level = {
               "",
               "Here is the only catch though -- `<source>` is now a place on the *remote* and `<destination>` is a *local* place to put those commits. It's the exact opposite of git push, and that makes sense since we are transferring data in the opposite direction!",
               "",
-              "That being said, developers rarely do this in practice. I'm introducing it mainly as a way to conceptualize how `fetch` and `push` are quite similar, just in opposite directions"
+              "That being said, developers rarely do this in practice. I'm introducing it mainly as a way to conceptualize how `fetch` and `push` are quite similar, just in opposite directions."
             ]
           }
         },
@@ -88,7 +88,7 @@ exports.level = {
               "Let's see this craziness in action:"
             ],
             "afterMarkdowns": [
-              "Wow! See, git resolved `foo~1` as a place on the origin and then downloaded those commits to `bar` (which was a local branch). Notice how `foo` and `o/foo` were not updated since we specified a destination"
+              "Wow! See, git resolved `foo~1` as a place on the origin and then downloaded those commits to `bar` (which was a local branch). Notice how `foo` and `o/foo` were not updated since we specified a destination."
             ],
             "command": "git fetch origin foo~1:bar",
             "beforeCommand": "git branch foo; git clone; git branch bar; git fakeTeamwork foo 2"
@@ -98,10 +98,10 @@ exports.level = {
           "type": "GitDemonstrationView",
           "options": {
             "beforeMarkdowns": [
-              "What if the destination doesnt exist before I run the command? Lets see the last slide but without `bar` existing beforehand"
+              "What if the destination doesn't exist before I run the command? Let's see the last slide but without `bar` existing beforehand."
             ],
             "afterMarkdowns": [
-              "See, it's JUST like git push. Git made the destination locally before fetching, just like git will make the destination on remote before pushing (if it doesn't exist)"
+              "See, it's JUST like git push. Git made the destination locally before fetching, just like git will make the destination on remote before pushing (if it doesn't exist)."
             ],
             "command": "git fetch origin foo~1:bar",
             "beforeCommand": "git branch foo; git clone; git fakeTeamwork foo 2"
@@ -116,7 +116,7 @@ exports.level = {
               "If `git fetch` receives no arguments, it just downloads all the commits from the remote onto all the remote branches..."
             ],
             "afterMarkdowns": [
-              "Pretty simple, but worth going over just once"
+              "Pretty simple, but worth going over just once."
             ],
             "command": "git fetch",
             "beforeCommand": "git branch foo; git clone; git fakeTeamwork foo; git fakeTeamwork master"

src/levels/remote/fetchRebase.js

@@ -57,7 +57,7 @@ exports.level = {
             "markdowns": [
               "How do you resolve this situation? It's easy, all you need to do is base your work off of the most recent version of the remote branch.",
               "",
-              "There are a few ways to do this, but the most straightforward is to move your work via rebasing. Let's go ahead and see what that looks like"
+              "There are a few ways to do this, but the most straightforward is to move your work via rebasing. Let's go ahead and see what that looks like."
             ]
           }
         },
@@ -107,7 +107,7 @@ exports.level = {
               "",
               "Of course -- you already know `git pull` is just shorthand for a fetch and a merge. Conveniently enough, `git pull --rebase` is shorthand for a fetch and a rebase!",
               "",
-              "Let's see these shorthand commands at work"
+              "Let's see these shorthand commands at work."
             ]
           }
         },
@@ -118,7 +118,7 @@ exports.level = {
               "First with `--rebase`..."
             ],
             "afterMarkdowns": [
-              "Same as before! Just a lot shorter"
+              "Same as before! Just a lot shorter."
             ],
             "command": "git pull --rebase; git push",
             "beforeCommand": "git clone; git fakeTeamwork; git commit"

src/levels/remote/mergeManyFeatures.js

@@ -31,7 +31,7 @@ exports.level = {
           "type": "ModalAlert",
           "options": {
             "markdowns": [
-              "Theres a lot of debate about the tradeoffs between merging and rebasing in the development community. Here are the general pros / cons of rebasing:",
+              "There's a lot of debate about the tradeoffs between merging and rebasing in the development community. Here are the general pros / cons of rebasing:",
               "",
               "Pros:",
               "",
@@ -51,7 +51,7 @@ exports.level = {
           "type": "ModalAlert",
           "options": {
             "markdowns": [
-              "For this level, let's try to solve the previous level but with *merging* instead. It may get a bit hairy but it illustrates the point well"
+              "For this level, let's try to solve the previous level but with *merging* instead. It may get a bit hairy but it illustrates the point well."
             ]
           }
         }

src/levels/remote/pull.js

@@ -19,14 +19,14 @@ exports.level = {
             "markdowns": [
               "## Git Pull",
               "",
-              "Now that we've seen how to fetch data from a remote repository with `git fetch`, lets update our work to reflect those changes!",
+              "Now that we've seen how to fetch data from a remote repository with `git fetch`, let's update our work to reflect those changes!",
               "",
               "There are actually many ways to do this -- once you have new commits available locally, you can incorporate them as if they were just normal commits on other branches. This means you could execute commands like:",
               "",
               "* `git cherry-pick o/master`",
               "* `git rebase o/master`",
               "* `git merge o/master`",
-              "* etc, etc",
+              "* etc., etc.",
               "",
               "In fact, the workflow of *fetching* remote changes and then *merging* them is so common that git actually make a command that does both at once! That command is `git pull`."
             ]

src/levels/remote/pullArgs.js

@@ -21,7 +21,7 @@ exports.level = {
               "",
               "Now that you know pretty much *everything* there is to know about arguments for `git fetch` and `git push`, there's almost really nothing left to cover for git pull :)",
               "",
-              "That's because git pull at the end of the day is *really* just shorthand for a fetch followed by merging in whatever was just fetched. You can think of it as running git fetch with SAME arguments specified and then merging in *where* those commits ended up.",
+              "That's because git pull at the end of the day is *really* just shorthand for a fetch followed by merging in whatever was just fetched. You can think of it as running git fetch with the *same* arguments specified and then merging in *where* those commits ended up.",
               "",
               "This applies even when you use crazy-complicated arguments as well. Let's see some examples:"
             ]
@@ -43,7 +43,7 @@ exports.level = {
               "",
               "`git fetch origin bar~1:bugFix; git merge bugFix`",
               "",
-              "See? git pull is really just shorthand for fetch + merge, and all git pull cares about is where the commits ended up (the `destination` argument that it figures out during fetch)",
+              "See? git pull is really just shorthand for fetch + merge, and all git pull cares about is where the commits ended up (the `destination` argument that it figures out during fetch).",
               "",
               "Lets see a demo:"
             ]

src/levels/remote/push.js

@@ -25,7 +25,7 @@ exports.level = {
               "",
               "`git push` is responsible for uploading _your_ changes to a specified remote and updating that remote to incorporate your new commits. Once `git push` completes, all your friends can then download  your work from the remote.",
               "",
-              "You can think of `git push` as a command to \"publish\" your work. It has a bunch of subtleties that we will get into shortly, but let's start with baby steps"
+              "You can think of `git push` as a command to \"publish\" your work. It has a bunch of subtleties that we will get into shortly, but let's start with baby steps."
             ]
           }
         },

src/levels/remote/pushArgs.js

@@ -42,7 +42,7 @@ exports.level = {
               "",
               "translates to this in English:",
               "",
-              "*Go to the branch named \"master\" in my repository, grab all the commits, and then go to the branch \"master\" on the remote named \"origin.\" Place whatever commits are missing on that branch and then tell me when you're done*",
+              "*Go to the branch named \"master\" in my repository, grab all the commits, and then go to the branch \"master\" on the remote named \"origin.\" Place whatever commits are missing on that branch and then tell me when you're done.*",
               "",
               "By specifying `master` as the \"place\" argument, we told git where the commits will *come from* and where the commits *will go*. It's essentially the \"place\" or \"location\" to synchronize between the two repositories.",
               "",
@@ -54,10 +54,10 @@ exports.level = {
           "type": "GitDemonstrationView",
           "options": {
             "beforeMarkdowns": [
-              "Let's see an example of specifying the arguments. Note the location where we are checked out in this example"
+              "Let's see an example of specifying the arguments. Note the location where we are checked out in this example."
             ],
             "afterMarkdowns": [
-              "There we go! `master` got updated on the remote since we specified those arguments"
+              "There we go! `master` got updated on the remote since we specified those arguments."
             ],
             "command": "git checkout C0; git push origin master",
             "beforeCommand": "git clone; git commit"
@@ -70,7 +70,7 @@ exports.level = {
               "What if we hadn't specified the arguments? What would happen?"
             ],
             "afterMarkdowns": [
-              "The command fails (as you can see), since `HEAD` is not checked out on a remote-tracking branch"
+              "The command fails (as you can see), since `HEAD` is not checked out on a remote-tracking branch."
             ],
             "command": "git checkout C0; git push",
             "beforeCommand": "git clone; git commit"

src/levels/remote/pushArgs2.js

@@ -60,7 +60,7 @@ exports.level = {
           "type": "GitDemonstrationView",
           "options": {
             "beforeMarkdowns": [
-              "What if the destination you want to push doesn't exist? No problem! Just give a branch name and git will create the branch on the remote for you"
+              "What if the destination you want to push doesn't exist? No problem! Just give a branch name and git will create the branch on the remote for you."
             ],
             "afterMarkdowns": [
               "Sweet, that's pretty slick :D"

src/levels/remote/pushManyFeatures.js

@@ -37,7 +37,7 @@ exports.level = {
           "type": "GitDemonstrationView",
           "options": {
             "beforeMarkdowns": [
-              "Let's see a refresher real quick of how to update `master` and push work"
+              "Let's see a refresher real quick of how to update `master` and push work."
             ],
             "afterMarkdowns": [
               "We executed two commands here that:",
@@ -59,7 +59,7 @@ exports.level = {
               "* We want to push each one of these features, in order, to the remote",
               "* The remote has since been updated, so we will need to incorporate that work as well",
               "",
-              ":O intense! good luck, completing this level is a big step"
+              ":O intense! good luck, completing this level is a big step."
             ]
           }
         }

src/levels/remote/remoteBranches.js

@@ -45,7 +45,7 @@ exports.level = {
               "",
               "Unfortunately the full name of `origin` does not fit in our UI, so we use `o` as shorthand :( Just remember when you're using real git, your remote is probably going to be named `origin`!",
               "",
-              "That's a lot to take in, so let's see this all in action."
+              "That's a lot to take in, so let's see all this in action."
             ]
           }
         },
@@ -66,7 +66,7 @@ exports.level = {
           "type": "ModalAlert",
           "options": {
             "markdowns": [
-              "To finish this level, commit once off of `master` and once after checking out `o/master`. This will help drive home how remote branches behave differently, and they only update to reflect the state of the remote"
+              "To finish this level, commit once off of `master` and once after checking out `o/master`. This will help drive home how remote branches behave differently, and they only update to reflect the state of the remote."
             ]
           }
         }