Issue #165 re naming conventions

README.md

@@ -30,14 +30,14 @@ This project aims to fix some of these problems by having materials and instruct
 
 This workshop provides a high-level overview of the steps, tools and tradecraft needed to introduce beginners to open source sprints. The workshop provides lecture/demo **AND** lots of hands-on in the following areas.
 
-* Using version control tools such as git and github
+* Using version control tools such as Git and GitHub
 * Hands-on: Creating additions and changes to an open source project
 * Getting those changes incorporated into the project via pull requests
 * Understanding, creating, and using virtual environments
 
 In addition, the overview will include numerous resources for self-study.
 
-This project is based on anaconda, git, and github for Python sprints.
+This project is based on Anaconda, Git, and GitHub for Python sprints.
 This project can be modified for the needs of other sprints and other languages.
 
 # Prerequisites

class_materials/git_branch_merge.md

@@ -28,7 +28,7 @@ Branches should be small and self-contained so that they can be merged easily. S
 
 A typical iteration of creating a feature (sometimes called a `feature branch`) would look like this:
 
-**Create a new branch** & cause `git` to begin tracking changes in that branch
+**Create a new branch** & cause Git to begin tracking changes in that branch
 
 ```bash
 $ git checkout -b appleseed-feature     # "-b" creates a new branch named "appleseed-feature"
@@ -123,7 +123,7 @@ Besides `git add`, `git commit`, `git push`, the next logical step is to grow fa
 $ git checkout -b appleseed-feature
 ```
 
-What makes a good branch name? What are the rules for naming branches? This is a short list of rules (for a complete list, see the [git man pages](https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-check-ref-format.html).
+What makes a good branch name? What are the rules for naming branches? This is a short list of rules (for a complete list, see the [Git man pages](https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-check-ref-format.html).
 
 * They cannot have two consecutive dots `..` anywhere
 * They cannot contain a `\`
@@ -147,7 +147,7 @@ $ git commit -m "added edits to johnny's history"
 
 #### Merge your changes into the master branch
 
-As noted above, `git checkout` allows you to change to an alternate branch. The `master` branch is created by default by `git` and is often used as the main branch for release. To change back to the `master` branch, use `git checkout master`. Often others may be working on the same codebase and some of those changes may impact your codebase, so it is critical to collect all of those changes (i.e. download them from the `upstream` repository) for comparison to your code, using `git pull`.
+As noted above, `git checkout` allows you to change to an alternate branch. The `master` branch is created by default by Git and is often used as the main branch for release. To change back to the `master` branch, use `git checkout master`. Often others may be working on the same codebase and some of those changes may impact your codebase, so it is critical to collect all of those changes (i.e. download them from the `upstream` repository) for comparison to your code, using `git pull`.
 
 For now, we will presume that there are no conflicts between your changes and other changes. With that premise in mind, you can merge your code and your local copy of the `upstream` repo.
 

class_materials/git_cloning.md

@@ -12,7 +12,7 @@
 
 With a fork of the project in your GitHub repository, it's time to `git clone` the project to your local computer, so you have a local copy on your machine to do work on. The project we will start with is a project that doesn't have any code in it. It is a project full of famous poems. This is on purpose. We want to start off by
 
-* practicing **the mechanics** of making changes and propogating those changes to the owner
+* practicing **the mechanics** of making changes and propagating those changes to the owner
 WHILE
 * **minimizing the fear** of breaking anything AND
 * **avoiding** having to figure out the nuances of someone else's code
@@ -48,7 +48,7 @@ The `clone` command will create a new folder in the `mytest` directory. Change d
 $ cd intro_to_sprinting_codeless_project
 ```
 
-Next, add a reference to the **original repo (i.e. Chalmer's repo)** using the `git remote` command. The reference is often referred to as an `upstream`:
+Next, add a reference to the **original repo (i.e., Chalmer's repo)** using the `git remote` command. The reference is often referred to as an `upstream`:
 
 ```bash
 $ git remote add upstream https://github.com/chalmerlowe/intro_to_sprinting_codeless_project.git
@@ -76,7 +76,7 @@ The following discussion will give you more insight into cloning repositories an
 $ git clone https://github.com/johnny_appleseed/intro_to_sprinting_codeless_project.git
 ```
 
-The `clone` command creates a folder, which should be full of project files. `git` will automatically set up a link to a repository and will give it the default name: `origin` as a **remote** repository. In this case, it will point to **your** GitHub fork of the repository.
+The `clone` command creates a folder, which should be full of project files. Git will automatically set up a link to a repository and will give it the default name: `origin` as a **remote** repository. In this case, it will point to **your** GitHub fork of the repository.
 
 If you are curious, and want to confirm the link and the name of the remote repository, you can use the `git remote -v` command:
 
@@ -90,7 +90,7 @@ Here we see that for the `origin` remote repository, we have the ability to fetc
 
 As part of committing to open source projects, we want to get updates from the original repository (often called the `upstream` repository) whenever the project developer makes changes so that we can confirm that nothing we have done will interfere with any other work being done on the project.
 
-To enable `git` to find the `upstream` we use the following command:
+To enable Git to find the `upstream` we use the following command:
 
 ```bash
 $ git remote add upstream https://github.com/chalmerlowe/intro_to_sprinting_codeless_project.git

class_materials/git_common_operations.md

@@ -12,7 +12,7 @@
 
 Git has a number of capabilities to simplify your life, help you understand the status of your directory and improve your ability to communicate about your changes.
 
-When using `git`, sometimes you want to know more about the changes you are committing ... this is where `git diff` comes in.
+When using Git, sometimes you want to know more about the changes you are committing ... this is where `git diff` comes in. 
 
 ## What to do
 
@@ -26,9 +26,10 @@ For this next exercise, we will change a single file and use the `git diff` tool
 $ git diff
 ```
 
-This will show you, in detail, the differences between the last version of the file that was committed via `git` and any changes you have since created. For details on how this is broken out, see the **Deep Dive** section.
+This will show you, in detail, the differences between the last version of the file that was committed via Git and any changes you have since created. For details on how this is broken out, see the **Deep Dive** section.
 
-Once you are done, you can restore the modified file to it's original state by typing `git checkout -- beowulf.txt`. This essentialy tells Git to "undo" any changes to that file that are not yet staged or committed.
+
+Once you are done, you can restore the modified file to it's original state by typing `git checkout -- beowolf.txt`. This essentially tells Git to "undo" any changes to that file that are not yet staged or committed.
 
 ## Done with commands for now!
 

class_materials/git_concepts.md

@@ -38,7 +38,7 @@ You can reach this video, here: [Git Happens](https://www.youtube.com/watch?v=yC
 
 ## Deep dive
 
-As noted above, `git` tracks changes to files in a database AND categorizes files in the following ways:
+As noted above, Git tracks changes to files in a database AND categorizes files in the following ways:
 
 ||Category|Analogy|
 |:---|:----|:----|

class_materials/git_config.md

@@ -30,20 +30,20 @@ If you (and your partner, if you're working in pairs) are done, then you can put
 
 ## The big picture
 
-These are the two fundamental configurations needed to use `git`.
+These are the two fundamental configurations needed to use Git.
 
-**Note:** The `--global` option applies these settings to all `git` projects on your machine
-* You only need to run this **once per computer**
-* To change a setting, simply re-run the command
-* To override these settings for a specific project (e.g., a work project versus a personal project), simply run the command while in that project directory, and leave out the `--global` option
+**Note:** The `--global` option applies these settings to all Git projects on your machine  
+* You only need to run this **once per computer**.  
+* To change a setting, simply re-run the command.  
+* To override these settings for a specific project (e.g., a work project versus a personal project), simply run the command while in that project directory, and leave out the `--global` option.
 
-Later sections of the workshop will go into greater depth on using `git`.
+Later sections of the workshop will go into greater depth on using Git.
 
 ## Deep dive
 
-`git` is a command-line tool, and as such you will be doing a lot of typing when you work with it. There are many configurations that can be set for `git` but they are outside the scope of this workshop.
+Git is a command-line tool, and as such you will be doing a lot of typing when you work with it. There are many configurations that can be set for Git but they are outside the scope of this workshop.
 
-Because `git` is a command-line tool, if you need a primer for the command line, check out the [Learn the command-line](https://www.codecademy.com/learn/learn-the-command-line) course on Codecademy. If you just need a quick reference, check out the cheatsheets in **Resources** section below.
+Because Git is a command-line tool, if you need a primer for the command line, check out the [Learn the command-line](https://www.codecademy.com/learn/learn-the-command-line) course on Codecademy. If you just need a quick reference, check out the cheatsheets in **Resources** section below.
 
 
 ## Resources

class_materials/git_main_lifecycle.md

@@ -30,7 +30,7 @@ With a freshly cloned repo, we can make some edits and revisions to the Codeless
 * If you type `ls` (or `dir` in Windows) you should see multiple files
 
 ### Status check
-At any time, we can check the status of our `git` repository. Before we change any files, let's check to see what the status of our repo is, by using `git status`
+At any time, we can check the status of our Git repository. Before we change any files, let's check to see what the status of our repo is, by using `git status`
 
 ```bash
 $ git status
@@ -68,7 +68,7 @@ Changes not staged for commit:
 ```
 
 ### Add the file to the staging area
-`git add` the file **you** edited to the git staging area using the `git add` command. **ENSURE** you replace `johnny_appleseed.txt` with the actual name of the file.
+`git add` the file **you** edited to the Git staging area using the `git add` command. **ENSURE** you replace `johnny_appleseed.txt` with the actual name of the file.
 
 ```bash
 $ git add johnny_appleseed.txt
@@ -81,7 +81,7 @@ $ git add <file1> <file2> ...
 ```
 
 ### Status check
-Take a look at things now that the file has been staged, again using `git status`... We should notice that a line in the output identifies that a text file has been modified AND is now ready to be committed.
+Take a look at things now that the file has been staged, again using `git status` ... We should notice that a line in the output identifies that a text file has been modified AND is now ready to be committed.
 
 ```bash
 $ git status
@@ -243,9 +243,9 @@ Here, like earlier, my working tree is again **clean** (all changes are committe
 
 ### Pushing files
 
-When pushing your commits to GitHub, the `git push` command will give you a summary of all the changes that it attempted to make. In the following case, we see that `git`:
+When pushing your commits to GitHub, the `git push` command will give you a summary of all the changes that it attempted to make. In the following case, we see that Git:
 
-* sent several objects (it is normal for multiple objects to be sent up even if you only changed one file. Those other items are internal to `git` and not critical for you to worry about now)
+* sent several objects (it is normal for multiple objects to be sent up even if you only changed one file. Those other items are internal to Git and not critical for you to worry about now).
 * compressed the data
 * wrote the data
 * reported back on where the data was sent
@@ -262,12 +262,12 @@ To github:myusername/my_repo.git
    98b2f3f..206546b  master -> master
 ```
 
-**About Hashes**: without going into the computer science behind it, `git` creates a unique value called a `hash` for every change that gets committed. Because hashes are unique values, they allow you to:
+**About Hashes**: without going into the computer science behind it, Git creates a unique value called a `hash` for every change that gets committed. Because hashes are unique values, they allow you to:
 
 * pick specific commits to examine OR
 * specific commits to revert back to, if you find you need to undo a change to your repository
 
-The seven digit numbers you see in `git` and on GitHub (e.g., `206546b`) identify a specific change and are a short form for a longer hash number.
+The seven digit numbers you see in Git and on GitHub (e.g., `206546b`) identify a specific change and are a short form for a longer hash number.
 
 Let's again use `git status` to look at the results of our work:
 

class_materials/git_merge_conflicts.md

@@ -18,7 +18,7 @@ If their changes are completely different from any changes we have made (i.e. if
 
 Similarly, if their changes are in the same file that we changed, but are in completely separate portions of the file, we can often merge without conflict.
 
-**But** if our changes are in the same file and overlap, it becomes difficult for `git` to automagically merge our changes. In those cases, `git` will turn over the merge process to us, to do manually, but will do its best to help.
+**But** if our changes are in the same file and overlap, it becomes difficult for Git to automagically merge our changes. In those cases, Git will turn over the merge process to us, to do manually, but will do its best to help.
 
 ## What to do
 
@@ -119,7 +119,7 @@ You will be told when to edit this file.
 ...
 ```
 
-Using your text editor, delete the lines that `git` added and any lines you don't want to retain. In this case, **keep change B**. Your final local file should look something like this:
+Using your text editor, delete the lines that Git added and any lines you don't want to retain. In this case, **keep change B**. Your final local file should look something like this:
 
 ```
 DO NOT EDIT THIS FILE (yet). B
@@ -151,11 +151,11 @@ If you like reading, you can also keep reading this page.
 
 Git has excellent algorithms to make best effort attempts to merge files even if two files differ significantly from one another. Despite this ability, sometimes changes are so complicated that Git gets lost and just can't decipher which part of each file should be retained.
 
-When you `git merge` and `git` finds a conflict, it makes a best effort to retain the conflicting portion of each file and present them to you in a single file. It annotates each section of conflicting content so you can compare the changes side-by-side in context. After generating this partially merged but conflicting file, `git` leaves it up to you to manually edit those portions of the file it annotated for you. Upon cleaning up the conflict, you proceed as normal: `git add`, `git commit`, `git push`.
+When you `git merge` and Git finds a conflict, it makes a best effort to retain the conflicting portion of each file and present them to you in a single file. It annotates each section of conflicting content so you can compare the changes side-by-side in context. After generating this partially merged but conflicting file, Git leaves it up to you to manually edit those portions of the file it annotated for you. Upon cleaning up the conflict, you proceed as normal: `git add`, `git commit`, `git push`.
 
 ## Deep dive
 
-To demonstrate how to merge a conflict, we want to try and create two versions of the same file with conflicting changes and cause `git` to attempt a merge.
+To demonstrate how to merge a conflict, we want to try and create two versions of the same file with conflicting changes and cause Git to attempt a merge.
 
 Under normal circumstances conflicts occur when a change is made to a file in your local repository and the same file in the upstream repository. This typically occurs because someone else edits the file and gets it incorporated in the upstream repo at the same time as you are making your changes.
 
@@ -180,7 +180,7 @@ DO NOT EDIT THIS FILE (yet). A
 
 **Commit the change**
 
-Click the **Commit Changes** button at the very bottom of the page. As implied by the button, GitHub considers any changes you make via this method to be no different that any other change that you `git add`, `git commit` using `git`. Since the change is being made on GitHub, you don't have to push the change up.
+Click the **Commit Changes** button at the very bottom of the page. As implied by the button, GitHub considers any changes you make via this method to be no different that any other change that you `git add`, `git commit` using Git. Since the change is being made on GitHub, you don't have to push the change up.
 
 It is not necessary, for this simple example, to add text to the empty fields. Normally, you would want to communicate the nature of the changes in the file in just the same way as you would document any other `git commit`. In fact, the two fields are exactly the same as if you provided a long-form `git commit` message with a subject and body.
 
@@ -257,7 +257,7 @@ Automatic merge failed; fix conflicts and then commit the result.
 
 **Confirm that a merge conflict occurred**
 
-If you use `git status`, you can always confirm which files had a merge conflict. They will be marked as having `Unmerged paths`. In this case, we see that both files were modified and `git` balked. There are also helpful hints to remind us what to do after we manually fix the conflicts OR to revert back and skip the merge altogether.
+If you use `git status`, you can always confirm which files had a merge conflict. They will be marked as having `Unmerged paths`. In this case, we see that both files were modified and Git balked. There are also helpful hints to remind us what to do after we manually fix the conflicts OR to revert back and skip the merge altogether.
 
 ```bash
 $ git status
@@ -278,7 +278,7 @@ no changes added to commit (use "git add" and/or "git commit -a")
 
 **Fix the conflict**
 
-Since `git` tells us what file failed to merge, we can immediately take a look. Open the file with a text editor and you should see that the file now includes:
+Since Git tells us what file failed to merge, we can immediately take a look. Open the file with a text editor and you should see that the file now includes:
 
 * text from both sources
 * three extra lines with special symbols to segregate the material in conflict from each other and from the file as a whole