Final changes

Signed-off-by: Matt Oswalt <[email protected]>

lessons/git-version-control/stage4/guide.md

@@ -10,7 +10,7 @@ One advantage of doing this is that remotes offer a sort of neutral "middle grou
 
 A very popular choice for this is Github, which is a hosted Git service, and allows you to create internet-accessible Git repositories that anyone can contribute to or pull from.
 
-It's useful to point out that everything we've talked about in this lesson thus far, including the concept of remotes in general, are core to Git itself. We will often refer to these as "Git fundamentals", meaning they apply to any software system or service like Github that is centered around Git. Services like Github, Gitlab, Bitbucket, Gitea, etc build on top of these fundamentals to add additional features to make it easier to collaborate on Git repositories. Things like Issues and Pull Requests are not built in to Git, but rather are features implemented by these services for the purposes of making Git a more collaborative experience on their platform.
+It's useful to point out that everything we've talked about in this lesson thus far, including the concept of remotes in general, are core to Git itself. We will often refer to these as "Git fundamentals", meaning they are the core features and tools within Git itself, and work the same way on any platform. Services like Github, Gitlab, Bitbucket, or Gitea build on top of these fundamentals by adding additional features for collaborating on Git repositories. Things like Issues and Pull Requests are not built in to Git, but rather are features implemented by these services for the purposes of making Git a more collaborative experience on their platform.
 
 We'll be using a few of these features in this chapter - but it's important to remember that there is an important distinction between platform-agnostic "git fundamentals" like commits and branches, and platform-specific features like Issues and Pull Requests that may vary from platform to platform. They are complementary, but Git is not the same thing as Github.
 
@@ -90,7 +90,7 @@ You may notice that on the last screen there's a section titled "Pushing an exis
 
 As we covered earlier, a "remote" is a Git repository that's running on another computer. Git allows us to define these remotes by name first, and then gives us commands to interact with these remotes - either pulling commits from them, or pushing commits to them.
 
-The first command that Gitea wants us to run - `git remote add` defines a new remote with the name of `origin`, and stores this in the local repository configuration `.git/config`. By the way, the name `origin` is a common convention for the name of a Git remote, but not required (in the second use case we'll encounter a need to actually have two remotes defined for the same repository). The final parameter for this command is the location for this remote - in this case, we're using the hostname `remote` to indicate the system we want to connect to, and then `jane/myfirstrepo.git` to specify the path to the repository.
+The first command that Gitea wants us to run (`git remote add`) defines a new remote with the name of `origin`, and stores this in the local repository configuration `.git/config`. The name `origin` is a common convention for the name of a Git remote, but not a strict requirement. The final parameter for this command is the location for this remote - in this case, we're using the hostname `remote` to indicate the system we want to connect to, and then `jane/myfirstrepo.git` to specify the path to the repository.
 
 Enter the `myfirstrepo` repository that we've been working with, and run this command to set up the remote:
 
@@ -119,6 +119,8 @@ This is actually a very common exercise. You might start work on a project by ju
 
 ### Use Case 2 - Contribute to Someone Else's Repository
 
+(This section runs a little long, so you may want to refresh the page here to ensure your lab environment stays active)
+
 The other big use case for working with Git remotes comes when you find an existing repository that belongs to someone else. Maybe this is a popular open source project, or maybe it's something as simple as a personal repository that belongs to a friend. In most cases, you don't have "write access" to these repositories - that is, you are not able to simply push a branch of commits directly to the repository.
 
 Instead, a "Fork and Pull" workflow is used, which goes something like this:
@@ -189,7 +191,7 @@ git checkout -b change-as-number
 
 Even if you want your work to be merged to the `master` branch of the upstream repository, this will still work. All popular platforms like Github are perfectly capable of merging from a non-standard branch in your repository into the `master` branch on the upstream repository.
 
-For this changes, we'll just change the configured autonomous system number for the `vqfx1.txt` file in this repository. This is just an example though - feel free to make any change you want using `nano` or `vim`:
+For this change, we'll just change the configured autonomous system number for the `vqfx1.txt` file in this repository. This is just an example though - feel free to make any change you want using `nano` or `vim`:
 
 ```
 sed -i s/64001/64010/ vqfx1.txt
@@ -236,13 +238,13 @@ The title and description on this screen is up to you - and is likely to be anot
 
 <div style="text-align:center;margin-top:30px;"><img style="max-width: 70%;" class="full" src="https://raw.githubusercontent.com/nre-learning/nrelabs-curriculum/git-stage-4-remotes/lessons/git-version-control/stage4/images/propened.png"></div>
 
-At this point, the PR is open, and conversation can take place within this page. You might get comments from a reviewer, asking for additional changes, in which case you can add commits to your local branch and re-run `git push`, and the PR will automatically be updated.
+At this point, the PR is open, and conversation can take place within this page. You might get comments from a reviewer, asking for additional changes, in which case you can add commits to your local branch and re-run `git push`, and the PR will automatically be updated. This process continues until the PR is either closed or merged back into the upstream repository.
 
 ## BONUS - How to stay up to date with upstream changes?
 
 Once again, Git is a distributed version control system, which means we **have** to expect that changes can and will happen all the time, and we have to be ready to incorporate these changes.
 
-Even though we've opened a Pull Request, the upstream project isn't going to wait for us. Keep in mind that some open source projects have thousands of contributors, with changes being merged all the time. It's actually quite common that shortly after opening a pull request, the upstream project continues to change, and sometimes these changes need to be brought back into our fork, so we can ensure we're working on the latest copy.
+Even though we've opened a Pull Request, the upstream project isn't going to wait for us. Keep in mind that some open source projects have thousands of contributors, with changes being merged all the time. It's actually quite common that shortly after opening a pull request, the upstream project continues to change, and sometimes these changes need to be brought back into our fork, so we can ensure we're working on the latest copy. However, our fork doesn't automatically update itself - this is something we have to do ourselves.
 
 Git actually allows us to configure multiple remotes in a given repository. Even though we cloned the `network-configs` repository from our fork (which is currently set to the remote named `origin`), we can add a second one for the purposes of pulling down changes from the upstream `initech` repository. This can be done using the same syntax we saw earlier - but note the name `upstream` so it's obvious where this remote comes from:
 
@@ -269,5 +271,5 @@ git push origin change-as-number
 ```
 <button type="button" class="btn btn-primary btn-sm" onclick="runSnippetInTab('linux1', this)">Run this snippet</button>
 
-The initial step of adding the `upstream` remote should only be done once, but the remaining commands can be done repeatedly whenever you need to get your pull request updated with the latest commits from the `master` branch you're trying to merge into.
+The initial step of adding the `upstream` remote should only be done once, but the remaining commands can be done repeatedly whenever you need to get your pull request updated with the latest commits from the upstream repository's `master` branch. Doing so helps to ensure your pull request can eventually get merged without problems.