Merge pull request #312 from nre-learning/git-updates

Updating stage 2 for git lesson and adding stage 3

CHANGELOG.md

@@ -2,6 +2,7 @@
 
 ## In development
 
+- Adding stage 3 to Git lesson, and updating stage1 and stage2 with more relevant details [#312](https://github.com/nre-learning/nrelabs-curriculum/pull/312)
 
 ## v1.1.0 - February 01, 2020
 

lessons/fundamentals/lesson-17-git/lesson.meta.yaml

@@ -28,10 +28,8 @@ stages:
     description: Your First Git Repository
   - id: 2
     description: Adding and Comitting Files
-
-  # TODO in v1.1.1
-  # - id: 3
-  #   description: Parallelizing Your Work With Git Branches
+  - id: 3
+    description: Parallelizing Your Work With Git Branches
   # TODO in v1.1.2
   # - id: 4
   #   description: Oops! I made a mistake.

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

@@ -11,6 +11,10 @@ Incidentally, in the world of Network Reliability Engineering, not only do we ha
 
 In this lesson, we'll learn the very basics of Git - enough to get you started using it in your network projects. Once you have a few of the commands in this lesson under your belt, there are a large number of resources on the internet that dive under the covers.
 
+It's worth mentioning, it can take time to really become comfortable with Git. Git in particular emphasizes robustness and flexibility over ease-of-use, so if during this lesson or your day-to-day use of Git you feel overwhelmed or frustrated, know this is normal. Git is something you continually learn more about and add muscle memory for over time - not something anyone is expected to master in a few days.
+
+In these exercises, we'll try to keep things as simple as possible, and focus on how to practically get started using Git. However, within these exercises, we'll also link frequently to [the Git book](https://git-scm.com/book/en/v2) which is available online for free, or in print form, which is a great resource to have when you want to dive deeper into a particular step of your Git workflow.
+
 ## Your First Repository
 
 We refer to a group of directories and files managed by Git as a "repository" (or often, a "repo"). By now you may already know how to create a directory in your favorite Linux distribution, and navigate into it:

lessons/fundamentals/lesson-17-git/stage2/configs/catchup.sh

@@ -0,0 +1,9 @@
+#!/bin/bash
+
+# Catch up from previous sections
+rm -rf /home/antidote/myfirstrepo
+mkdir -p /home/antidote/myfirstrepo
+cd /home/antidote/myfirstrepo
+git init
+git config --global user.email "jane@nrelabs.io"
+git config --global user.name "Jane Doe"

lessons/fundamentals/lesson-17-git/stage2/configs/linux1.py

@@ -12,10 +12,6 @@ def createSSHClient(server, port, user, password):
 
 ssh=createSSHClient(host,22,"antidote","antidotepassword")
 
-ssh.exec_command('rm -rf /home/antidote/myfirstrepo')
-ssh.exec_command('mkdir -p /home/antidote/myfirstrepo')
-ssh.exec_command('cd /home/antidote/myfirstrepo && git init')
-ssh.exec_command('cd /home/antidote/myfirstrepo && git config --global user.email "jane@nrelabs.io"')
-ssh.exec_command('cd /home/antidote/myfirstrepo && git config --global user.name "Jane Doe"')
+ssh.exec_command('/antidote/stage2/configs/catchup.sh')
 
 ssh.close()

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

@@ -1,10 +1,13 @@
 # Version Control with Git
 ## Part 2 - Adding and Comitting Files
 
-A Git repository is nothing without some files to manage. Within our new repo, let's create a text file and add some text to it:
+A Git repository is nothing without some files to manage. We have a sample configuration for a Junos device's
+network interfaces, and we can copy this file into our new repository after entering into it:
+
 
 ```
-cd ~/myfirstrepo/ && echo "this is some text" > newfile.txt
+cd ~/myfirstrepo/
+cp /antidote/stage2/interface-config.txt .
 ```
 <button type="button" class="btn btn-primary btn-sm" onclick="runSnippetInTab('linux1', this)">Run this snippet</button>
 
@@ -18,7 +21,7 @@ git status
 Note that the file exists, but Git is listing it as "untracked". This means Git knows the file is there, but is otherwise not paying attention to it. The first thing we need to do is add this file to a special Git environment known as "staging". This is a temporary bucket to place changes to files before we're ready to make a commit. This is done using `git add`:
 
 ```
-git add newfile.txt
+git add interface-config.txt
 ```
 <button type="button" class="btn btn-primary btn-sm" onclick="runSnippetInTab('linux1', this)">Run this snippet</button>
 
@@ -38,10 +41,17 @@ git diff --cached
 ```
 <button type="button" class="btn btn-primary btn-sm" onclick="runSnippetInTab('linux1', this)">Run this snippet</button>
 
-The key concept with Git, especially when compared with other version control systems, is that it works on **changes** to files. We've added the file `newfile.txt` to staging, which was previously untracked, and therefore every line in that file is now in our staging environment. However, watch what happens when we add another line to the file:
+The key concept with Git, especially when compared with other version control systems, is that it works on **changes** to files. We've added the file `interface-config.txt` to staging, which was previously untracked, and therefore every line in that file is now in our staging environment. However, watch what happens when we add additional configuration to our file using some bash-foo, and then re-run `git status`:
 
 ```
-echo "this is even more text!" >> newfile.txt
+cat <<EOT >> ~/myfirstrepo/interface-config.txt
+vlans {
+    default {
+        vlan-id 1;
+    }
+}
+EOT
+
 git status
 ```
 <button type="button" class="btn btn-primary btn-sm" onclick="runSnippetInTab('linux1', this)">Run this snippet</button>
@@ -57,7 +67,7 @@ git diff
 There are a few things we can do at this point, depending on what we wanted to do with the additional change. Let's say we want to get rid of the second change, but keep the first in staging. In this case, the `git checkout` command can help us. By specifying this command with the name of the file, we're telling Git to revert back to the last known change for that file, which in this case is the one in staging:
 
 ```
-git checkout newfile.txt
+git checkout interface-config.txt
 ```
 <button type="button" class="btn btn-primary btn-sm" onclick="runSnippetInTab('linux1', this)">Run this snippet</button>
 
@@ -70,12 +80,12 @@ git status
 
 ## Your First Commit
 
-Now that we have all our desired changes in staging we can create our first commit! A commit is a way of marking a particular state of a repository, saying "I would like to remember what things were like at this point in time, so I can go back to it if I need to. Often, a commit is made when a developer makes a meaningful change to some code, or an NRE updates a YAML file with a new set of variables for a switch install. No matter the use case, **the commit is king** - if it's not in a commit, Git isn't permanently tracking that change yet.
+Now that we have all our desired changes in staging we can create our first commit! A commit is a way of marking a particular state of a repository, saying "I would like to remember what things were like at this point in time, so I can go back to it if I need to". Often, a commit is made when a developer makes a meaningful change to some code, or an NRE updates a YAML file with a new set of variables for a switch install. No matter the use case, **the commit is king** - if it's not in a commit, Git isn't permanently tracking that change yet.
 
 Once we've used `git add` to include all the changes we want to commit into staging, we can use `git commit` to save those changes in a commit.
 
 ```
-git commit -m "My first commit!"
+git commit -m "Adding new interface configuration file"
 ```
 <button type="button" class="btn btn-primary btn-sm" onclick="runSnippetInTab('linux1', this)">Run this snippet</button>
 
@@ -96,15 +106,13 @@ git log --oneline
 ```
 <button type="button" class="btn btn-primary btn-sm" onclick="runSnippetInTab('linux1', this)">Run this snippet</button>
 
-At this point, you may be wondering what those jumbled letters and numbers are to the left of the screen. Each commit
-gets its own cryptographic hash that uniquely identifies it. This is made using a combination of the date/time the commit
-was made, the contents of the commit, the parent commit (the commit before this one, if any), and a few other things.
+At this point, you may be wondering what those jumbled letters and numbers are to the left of the screen. Each commit gets its own cryptographic hash that uniquely identifies it. This is made using a combination of the date/time the commit was made, the contents of the commit, the parent commit (the commit before this one, if any), and a few other things.
 
 If you look carefully at the output of the command `git commit`, which we ran a few steps ago, it actually gives you an abbreviated form of this commit ID right away - in this case, the ID is `bdb4902`:
 
 ```
-antidote@linux1:~/myfirstrepo$ git commit -m "My first commit!"
-[master (root-commit) bdb4902] My first commit!
+antidote@linux1:~/myfirstrepo$ git commit -m "Adding new interface configuration file"
+[master (root-commit) bdb4902] Adding new interface configuration file
 ...
 ```
 

lessons/fundamentals/lesson-17-git/stage2/interface-config.txt

@@ -0,0 +1,30 @@
+interfaces {
+    em0 {
+        unit 0 {
+            family inet {
+                address 10.0.0.15/24;
+            }
+        }
+    }
+    em1 {
+        unit 0 {
+            family inet {
+                address 169.254.0.2/24;
+            }
+        }
+    }
+    em3 {
+        unit 0 {
+            family inet {
+                address 10.31.0.11/24;
+            }
+        }
+    }
+    em4 {
+        unit 0 {
+            family inet {
+                address 10.12.0.11/24;
+            }
+        }
+    }
+}

lessons/fundamentals/lesson-17-git/stage3/bumbling-fred.sh

@@ -0,0 +1,11 @@
+#!/bin/bash
+
+# This script simulates fred not only making a commit directly on `master` (which isn't very team-friendly)
+# but also changing the same line we're working on in our branch, which means we'll have a merge conflict
+# when we merge our branch back to master
+
+git checkout master > /dev/null 2>&1
+sed -i s/10.31.0.11/123.123.123.123/ interface-config.txt > /dev/null 2>&1
+git add interface-config.txt > /dev/null 2>&1
+git commit -m "I'm fred and I'm conficting with your change!" > /dev/null 2>&1
+git checkout change-123 > /dev/null 2>&1

lessons/fundamentals/lesson-17-git/stage3/change-approval.sh

@@ -0,0 +1,9 @@
+#!/bin/bash
+
+# This script simulates a change approval for change 124 occurring while we're working on a branch
+# for change 123. It checks out master, then merges 124 into master, and then checks out change 123
+# so we can see the difference between our 123 change and the new master branch
+
+git checkout master > /dev/null 2>&1
+git merge change-124 master > /dev/null 2>&1
+git checkout change-123 > /dev/null 2>&1

lessons/fundamentals/lesson-17-git/stage3/configs/catchup.sh

@@ -0,0 +1,25 @@
+#!/bin/bash
+
+# Catch up from previous sections
+rm -rf /home/antidote/myfirstrepo
+mkdir -p /home/antidote/myfirstrepo
+cd /home/antidote/myfirstrepo
+git init
+git config --global user.email "jane@nrelabs.io"
+git config --global user.name "Jane Doe"
+cp /antidote/stage3/interface-config.txt .
+git add interface-config.txt
+git commit -m "Adding new interface configuration file"
+
+# simulate Fred's change
+git config --global user.email "fred@nrelabs.io"
+git config --global user.name "Fred Smith"
+git checkout -b change-124
+sed -i s/10.12.0.11/10.12.0.12/ interface-config.txt
+git add interface-config.txt
+git commit -s -m "Updated em4 IP address"
+
+# Prepare for learner
+git config --global user.email "jane@nrelabs.io"
+git config --global user.name "Jane Doe"
+git checkout master

lessons/fundamentals/lesson-17-git/stage3/configs/linux1.py

@@ -0,0 +1,17 @@
+import paramiko
+import os
+from scp import SCPClient
+
+host=os.environ['SYRINGE_TARGET_HOST']
+
+def createSSHClient(server, port, user, password):
+    client = paramiko.SSHClient()
+    client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
+    client.connect(server, port, user, password)
+    return client
+
+ssh=createSSHClient(host,22,"antidote","antidotepassword")
+
+ssh.exec_command('/antidote/stage3/configs/catchup.sh')
+
+ssh.close()