Final stage3 fixes

Signed-off-by: Jane Doe <jane@nrelabs.io>

lessons/fundamentals/lesson-17-git/stage3/guide.md

@@ -1,7 +1,7 @@
 # Version Control with Git
 ## Part 3 - Parallelizing Your Work With Git Branches
 
-As Git is a distributed version control system, it's often the case that you want to work in parallel with either other engineer, or even yourself, as you work on different aspects of a given repository. Imagine you have two change windows, one of which is more complicated but happens a few weeks away, and another which is tomorrow night but is fairly simple. If you have your configurations or scripts for these changes in a Git repository, it's likely that you'll have to work on both at the same time at some point, which making sure the two changes don't step on each other in the process.
+As Git is a distributed version control system, it's often the case that you want to work in parallel with either other engineer, or even yourself, as you work on different aspects of a given repository. Imagine you have two change windows, one of which is more complicated but happens a few weeks away, and another which is tomorrow night but is fairly simple. If you have your configurations or scripts for these changes in a Git repository, it's likely that you'll have to work on both at the same time at some point, while making sure the two changes don't step on each other in the process.
 
 Enter the concept of "[branching](https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell)" in Git, to solve this exact problem. Using branches, we can effectively manage two "versions" of the repository, making commits all along the way, and then only once we're ready, merge them back together (if that's what we want to do).
 
@@ -38,7 +38,7 @@ git checkout -b change-123
 
 If you went through the previous section, `git checkout` will look familiar to you. In this case, we're using this command with the `-b` flag to simultaneously create and switch to a new branch entitled `change-123`. This means that not only does the branch exist, but any commits we make will be made on this branch.
 
-> By the way, Git is full of shortcuts. As you continue in your Git journey, you'll notice that many commands in Git, like the one we just ran are just shortcuts for common workflows that might require 2 or more git commands to perform.
+> By the way, Git is full of shortcuts. As you continue in your Git journey, you'll notice that many commands in Git, like the one we just ran are just shortcuts for common workflows that might otherwise require 2 or more separate commands to perform.
 
 Let's say that for change #123, we want to change the IP address of em3 from `10.31.0.11` to `10.31.0.12`.
 You can do this yourself using one of the provided text editors like `vi` or `nano`, or you can run the below `sed` command to do it in in a one-liner:
@@ -73,14 +73,14 @@ git show
 
 ## Playing Catch-Up
 
-As was mentioned previously, Git branching is a powerful tool to have when multiple work streams are going on simultaneously. Let's say Fred is also working on his own change ticket (#124) which changes the IP address of em4, in branch `change-124`. Let's say that the change review board likes Fred better than you so his change gets approved before yours. Since we haven't managed to run fast enough to capture fred and upload his brain into this lesson, we built a script to simulate this taking place. Run this script to merge Fred's change into the `master` branch:
+As was mentioned previously, Git branching is a powerful tool to have when multiple work streams are going on simultaneously. Let's say Fred is also working on his own change ticket (#124) which changes the IP address of em4, in branch `change-124`. Let's say that the change review board likes Fred better than you so his change gets approved before yours. Since we haven't managed to run fast enough to capture Fred and upload his brain into this lesson, we built a script to simulate this taking place. Run this script to merge Fred's change into the `master` branch:
 
 ```
 /antidote/stage3/change-approval.sh
 ```
 <button type="button" class="btn btn-primary btn-sm" onclick="runSnippetInTab('linux1', this)">Run this snippet</button>
 
-Now, that suck-up Fred's change is present on the `master` branch while you're still working in `change-123`. This means your branch is actually simultaneously **behind** and **ahead** of `master`, in that your branch has commits that `master` doesn't have, but the reverse is also true.
+Now, Fred's change is present on the `master` branch while you're still working in `change-123`. This means your branch is actually simultaneously **behind** and **ahead** of `master`, in that your branch has commits that `master` doesn't have, but the reverse is also true.
 
 One cool trick is that we can actually use the `git diff` command to compare entire branches, not just files, changes or commits. By comparing the `change-123` branch (our currently checked-out branch) with `master`, we can see that not only is our change to `em3` shown, but also Fred's change to `em4`:
 
@@ -93,7 +93,7 @@ Fortunately, this is fairly easy to remedy, and a fairly common occurrence. Imag
 
 The simplest and most common way to integrate these changes into your branch is via the `git merge` command. In short, this creates a commit which brings the contents of another branch into the one you have checked out. In this case, it brings the updates to the `master` branch that were created for change #124 into our branch so we can ensure we're working from the latest possible commit. This reduces the things we'll have to reason about when comparing our branch to `master`, and in some cases, prevent problems when we try to merge.
 
-> You can also use a concept called ["rebasing"](https://git-scm.com/book/en/v2/Git-Branching-Rebasing) to catch your branch up with the lastest changes from another branch. However, this works very differently to a simple merge, and is often better used for other niche use cases where it's needed. We will cover rebasing in a future section. For now, stick with `git merge`.
+> (You can also use a concept called ["rebasing"](https://git-scm.com/book/en/v2/Git-Branching-Rebasing) to catch your branch up with the latest changes from another branch. However, this works very differently to a simple merge, and is often better used for other niche use cases where it's needed. We will cover rebasing in a future section. For now, stick with `git merge`).
 
 ```
 git merge master change-123 -m "Merge branch 'master' into change-123"
@@ -148,7 +148,7 @@ The way to fix this is to open the file `interface-config.txt`, as Git will inse
 
 The anatomy is simple - there are two distinct sections we must choose from. Everything between the first set of arrows (`<<<<<<< HEAD`) and the line of equal signs (`=======`) is the valid change we've been working on. We know this because it's titled `HEAD`, which is currently pointing at our branch. Everything after the equal signs up to the second line of arrows (`>>>>>>> master`) is what we're trying to merge into our branch, in this case, the changes Fred made in `master`.
 
-Resolving conflicts like this are first and foremost a text editing process. We literally need to edit the text shown above so that we are left with only the text we want in this file. This means removing all of the lines that Git inserted, as well as the text of the change we want to keep. Note that this choice is entirely up to you. You could choose to keep both changes, none of them, or even made an additional change to truly resolve the problem. It is entirely up to the context of the conflict. In this case, however, we want to totally get rid of Fred's change.
+Resolving conflicts like this are first and foremost a text editing process. We literally need to edit the text shown above so that we are left with only the text we want in this file. This means removing all of the lines that Git inserted, as well as the actual contents of the change we want to discard. Note that this choice is entirely up to you. You could choose to keep both changes, none of them, or even make an additional change to truly resolve the problem. It is entirely up to the context of the conflict. In this case, however, we want to totally get rid of Fred's change.
 
 You can edit this file with `nano` (don't forget to save by pressing Ctrl+`x`, `y`, and then "Enter"), or, you can run this handy bash-foo for doing it in a one-liner. Note this is only for simplicity in this lesson - you'll definitely want to get comfortable with making these changes in your own text editor: