hmm

_units/branching.md

@@ -61,9 +61,11 @@ This creates a new branch and moves you onto that branch. You can list your curr
 
 ```
 
+Notice the asterisk __*__ denotes your current branch.
+
 ## Navigating Branches
 
-Move between branches with the `checkout` command.
+Move between branches with the `checkout` command without the `-b` option.
 
 ```bash
 
@@ -131,11 +133,10 @@ If you don't need that branch anymore you can delete it now. When you list your
 
 ## Try It Out
 
-Practice making branches, editing your files, commiting those changes and merging branches. Don't be afraid to test the limits a bit. 
+1. Practice making branches, editing your files, commiting those changes and merging branches. Don't be afraid to test the limits a bit. 
 
 
-### Advanced
-Try making two new branches, `foo-bar` and `foo-baz`.  Change `Lorem ipsum` in the beginning of the file to different things in each branch. 
+2. Try making two new branches, `foo-bar` and `foo-baz`.  Change `Lorem ipsum` in the beginning of the file to different things in each branch. 
 Merge both into master (not into each other). What happens?
 
 

_units/collaborating_with_github.md

@@ -67,7 +67,7 @@ We'll introduce a couple new features that help you collaborte. Then we'll move
 
 ## Pull Requests
 
-Pull requests are just a formal way of doing a merge. It is specific to GitHub, (i.e. not part of Git).Pull requests provide mechanisms and protections
+Pull requests are just a formal way of doing a merge. It is specific to GitHub, (i.e. not part of Git). Pull requests provide mechanisms and protections
 to control how branches are merged among collaborators and provide opportunities for quality control and review.
 
 To start, go to your terminal, and create a new branch in the local repository you clone from your neighbor. Make some edits, then push that branch up to GitHub.
@@ -88,6 +88,8 @@ Go to the GitHub repository. Most times you should see a yellow banner with a gr
 dropdown for **_base: master_**. Make sure the other one says **_compare: pull-branch_**. The comment is optional but a good idea. Notice there 
 are options to assign reviewers and asigness (the person to do the actual merge). The other options we'll touch on later. Click **_Create pull request_**. 
 
+<img src="/assets/img/getting_started_with_github/pull_flash.png" alt="Flash message for pull request." width="800">
+
 This doesn't actually merge it yet. It does just what it says, it creates a **_pull request_**, which is a suspended merge. If 
 you click on the *Pull Requests* tab, you see this request. You'll see references to reviews, the changes proposed in this request, and 
 also that there are no merge conflicts. Although there are other tests that can be performed here as well, its beyond the scope of this tutorial. 

_units/getting_started_with_github.md

@@ -70,19 +70,20 @@ have a local repository lets do that first.
 
 In either case you will need to create a GitHub repository. 
 
-1. At the GitHub website click **_New_** (or **_Start a Project_**). 
+1. At the GitHub website click **_New_** <img src="/assets/img/getting_started_with_github/start_project.png" width="36" alt="new button"> 
+(or **_Start a Project_**) <img src="/assets/img/getting_started_with_github/new_project.png" width="96" alt="Start a project button">. 
 2. Give your repository a name, usually the same as your local repository but it doesn't have to be. 
 3. It is good, but optional to give it a description. 
 4. Choose the public option. You have to pay to make private repositories.
 5. Go ahead and make a README. It is always a good idea to have a README. 
 6. You can also choose a license too if you want. 
 7. Also create a .gitignore.
-8. Click **_Create Repository_**. GitHub does a pretty good job at suggestion best practices, and its usually a good idea to follow them.
+8. Click the green **_Create Repository_**. GitHub does a pretty good job at suggestion best practices, and its usually a good idea to follow them.
 
 If you already have a local repository go to **Linking a Local Repository**, otherwise go to **Cloning a Repository**.
 if you don't have a local repository yet.
 
-# Linking a Local Repository
+## Linking a Local Repository
 
 
 
@@ -92,11 +93,15 @@ On your new repository landing page you should see a green **_Clone or download_
 You should see a url that looks something like `https://github/<user_name>/<repo_name>.git`.. Copy it to your clip board and on your local machine, 
 enter the following in your terminal.
 
+<img src="/assets/img/getting_started_with_github/clone_expanded.png" alt="Clone or download with https." width="400">
+
 > NOTE: HTTPS and SSH cloning both work. HTTPS is usually easier UNLESS you have set up two-factor
 > authentication  (2FA) in GitHub, then HTTPS will not work. In that case, you need to set up 
 [SSH keys](https://help.github.com/en/github/authenticating-to-github/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent) for your local repository
 > and [register them in GitHub](https://help.github.com/en/github/authenticating-to-github/adding-a-new-ssh-key-to-your-github-account).
 
+Now you need to tell your local repository where your remote repository in GitHub is. In your terminal do the following.
+
 ```bash
 
 > git remote add origin https://github.com/<user_name>/<repo_name>.git
@@ -117,6 +122,8 @@ Now we do a little Texas Two-Step to so that our local and remote repositories a
 ```bash 
 
 > git pull origin master  # you may have to add --allow-unrelated-histories
+## OR ##
+> git pull origin master --allow-unrelated-histories
   # git pull origin master --allow-unrelated-histories
   #  Response will very some.
   # From github.com:olendorf/learning_git
@@ -147,7 +154,7 @@ and if one doesn't exist, it's created for you.
 
 
 
-# Cloning a GitHub Repository
+## Cloning a GitHub Repository
 
 If don't already have a local repository, but there is a project on GitHub you would like to work on, you can clone it. This is actually very easy.
 Get the repositories URL/URI and on your local machine's terminal enter...
@@ -161,8 +168,23 @@ Get the repositories URL/URI and on your local machine's terminal enter...
 
 ```
 
+You can get the URI by clicking on the clipboard icon on you get when you click on the green **Clone or download** button.
+
 That's it! It's easier than dealing with an existing repository, but in practice both methods are common.
 
+## Forking A GitHub Repository
+
+There is still another way to create a repository. You can **Fork** someone elses repository to your own account that you can 
+then modify independently. There are two reasons to fork a repository. First, you may want to make a contribution to their work. 
+In which case, you would fork the repository, make the changes you like, then submit a **pull request** to the original 
+repository that will allow the owner to incorporate your changes if they so choose. The other common scenario is that
+you would like to use the repository as a jumping off point for your own project. Often these repositories are templates created 
+just for that purpose.
+
+Forking a repository is easy. Go to [this repository](https://github.com/NCSU-Libraries/ncsu_apprentice). Click the fork 
+button <img src="/assets/img/getting_started_with_github/fork_button.png" width="60">. Choose your own account, and in a few 
+seconds you will have a copy of it. 
+
 ## Try It Out
 
 You actually know most of what you need to know to work with GitHub on your own. For the most part working with GitHub. You work locally 

_units/navigating.md

@@ -12,11 +12,8 @@ instructors_notes: true
 # Provide a brief description of what the unit is about. You can use markdown
 # notation for this.
 description: |
-  Sometimes we need to do some slightly more complicated interactions with our git version tree.
-  This especially happens when we have made some mistakes that we have to deal with. Maybe we 
-  haven't been careful about committing changes often enough, or even just made a huge mess of things.
-  Fortunately only in the worst situations is most of your work not recoverable, and only if you have 
-  been very negligent in your committing and branching. 
+  - Learn how to move between commits
+  - Learn three two ways to undo work
 
 instructors_note: |
   1. Create a new branch
@@ -46,7 +43,7 @@ as we'll see in future units, having more collaborators often requires some tree
 Fortunately only in the worst situations is most of your work not recoverable, and only if you have 
 been negligent in your committing and branching. 
 
-## Going Back to Your Last Commit.
+## Undoing Uncommited Work
 
 Its not unusual to realize your work has gone a bit awry. If you commit often, its often the best course of action to go back to your 
 last commit. First lets add another file. Download the [example_file_2.png](/supporting_files/example_file_2.png) and put it in y
@@ -110,27 +107,131 @@ thing though, just the first 6-8 characters will usually do. You can see what th
 
 ```
 
-You can go back to your master branch and reset to that commit with the following.
+You will typically checkout previous commits while trying to figure out where your last good commit was made, or while
+tracking down the origin of some bad work. Once you have found the commit you want you can revert it.
+
+
+
+## Revert To A Previous Commit
+
+Ideally you never commit work that isn't perfect. In the real world you never commit work that isn't perfect. Sometimes
+the best way to fix that is to revert to a previous commit. Git gives us the `revert` command for that.
+
+```bash
+
+# Make some edits.
+> git add -A
+> git commit -m "one commit"
+# Make some edits.
+> git add -A
+> git commit -m "two commit"
+# Make some edits.
+> git add -A
+> git commit -m "three commit"
+# Make some edits.
+> git add -A
+> git commit -m "four commit"
+
+> git log
+# Get the MD5 hash of "two commit"
+
+> git revert df1eb3006
+
+```
+
+Revert doesn't actually roll back all your other commits. In Git, it is considered very
+bad to rewrite history. Instead it takes the commit you specify, and puts that state 
+in front of the commits your rolling back. Conceptually, your tree would look
+something like 
+
+**one commit** -> **two commit** -> **three commit** -> **four commit** -> **two commit**
+
+You can verify this by using `git log`.
 
 ```bash
 
-> git checkout master
-> git reset --hard  4403fe02
+> git log
+# commit c54730a9384811b4adbc65bd6d902cf6e3c35468 (HEAD -> new-branch)
+# Author: Robert Olendorf <[email protected]>
+# Date:   Mon Oct 28 12:37:06 2019 -0400
+# 
+#     Revert "two commit"
+#     
+#     This reverts commit df1eb3006e7ec1fb3f59dc8fdb40b117b07ab19e.
+# 
+# commit 33508a1b308c922c2cdf4f564263b2c31065d527
+# Author: Robert Olendorf <[email protected]>
+# Date:   Mon Oct 28 12:36:58 2019 -0400
+# 
+#     four commit
+# 
+# commit 8d38ac1cd60a0bc2167c1c473189b3f78d3c9b53
+# Author: Robert Olendorf <[email protected]>
+# Date:   Mon Oct 28 12:36:03 2019 -0400
+# 
+#     three commit
+# 
+# commit df1eb3006e7ec1fb3f59dc8fdb40b117b07ab19e
+# Author: Robert Olendorf <[email protected]>
+# Date:   Mon Oct 28 12:35:43 2019 -0400
+# 
+#     two commit
+# 
+# commit a027f097535dc9fad416dd681db3db52a87af085
+# Author: Robert Olendorf <[email protected]>
+# Date:   Mon Oct 28 12:35:20 2019 -0400
+# 
+#     one commit
+# 
+# commit 4c396b1742bab9970b3cd1f595e65067fd1e3197
+# Author: Robert Olendorf <[email protected]>
+# Date:   Mon Oct 28 12:34:33 2019 -0400
+# 
+#     fo0
+# 
+# commit 6a074a6f23ce02709ebeeb00dfbc0a66b5fa6a9b (master)
+# Author: Robert Olendorf <[email protected]>
+# Date:   Mon Oct 28 09:10:54 2019 -0400
+# 
+#     initial commit
 
 ```
 
 
-### Catching Your Branch Up With The Base Branch
+## Catching Your Branch Up With The Base Branch
 
 If you are careful and make branches with your new work, you should rarely have to walk back more 
 than one commit. More common on large projects with lots of collaborators you will need to move the base branch 
 up to your working  branch to get the most recent work. This is called **rebasing** and is pretty much a merge, but
-is used to move a working branch's history up so that it contains the most recent commits from a base branch. If you don't have
-a branch off master make one now. Then go back to *master* and make a few changes and commits.
+is used to move a working branch's history up so that it contains the most recent commits from a base branch. 
+
+If you don't have a branch off master make one now. 
+
+```bash
+
+> git checkout -b rebase-branch
+
+```
+
+Then go back to *master* and make a few changes and commits.
+
+```bash
+
+> get checkout master
+# Make some edits
+
+> git commit -m "first master commit"
+# Make some edits.
+
+> git commit -m "second master commit"
+
+```
+
+Then checkout your `rebase-branch` again and do the following.
 
 ```bash
 
-> git checkout new-branch
+> git checkout rebase-branch
 > git rebase master
   # First, rewinding head to replay your work on top of it...
   # Fast-forwarded new-branch to master.
@@ -139,7 +240,9 @@ a branch off master make one now. Then go back to *master* and make a few change
 
 ## Try It Out
 
-Try making a number of commits, then walking them back. Make some changes to your master branch and rebasing a side branch. 
+- Make some changes to your file then `reset` them.
+
+- Try making a number of commits, then walking them back. Make some changes to your master branch and rebasing a side branch.