Let's get into Git version control as a networker trying to get into programming. This is not a blog covering all the different Git commands, (we will use a couple). Rather an idea of how you can template your Git repositories. Whether you plan to put them onto GitHub or not.
Overview
Quick WSL Install
The first step I took was setting up a Linux environment in which I can easily interact with and code on.
To do this, I utilized Windows Subsystem for Linux (WSL).
Simply open PowerShell and issue the following command.
wsl --install This will simply install the default Ubuntu version (you can change the Linux distribution if you wish, but this is not the focus at the moment, so we will continue with the default). You will be taken through an installation wizard where you will need to configure your Linux username and password (e.g. user: mccube | password: madness).
Once running, you should be presented with a new prompt...
mccube@McSurface:~$ Create Working Directory
In this new Linux terminal, we will create 2 new folders: our Master folder and then our first Repository folder. For this, we will use the 'mkdir' (make directory) command.
mccube@McSurface:~$ mkdir devNetProjects
mccube@McSurface:~$ mkdir devNetProjects/MyFirstRepoLet's now jump into the folder MyFirstRepo using the 'cd' (change directory) command.
mccube@McSurface:~$ cd devNetProjects/MyFirstRepo
mccube@McSurface:~/devNetProjects/MyFirstRepo$Virtual Environments
We are off to a great start, but we should take a minute to discuss some best practices.
First, we want to use a virtual environment. Simply put, this helps isolate your program from your system. I have gotten into the habit of setting up a new virtual environment for each new project. If you perform an 'ls' command, you will see MyFirstRepo is empty.
mccube@McSurface:~/devNetProjects/MyFirstRepo$ ls
mccube@McSurface:~/devNetProjects/MyFirstRepo$Now we will create the virtual environment in Python. It is common to see the virtual environment called 'venv', but to make it stand out, I will call mine 'MyVirtEnv'. The following command uses 'Python3' to make a virtual environment called 'MyVirtEnv'.
mccube@McSurface:~/devNetProjects/MyFirstRepo$ python3 -m venv MyVirtEnv
mccube@McSurface:~/devNetProjects/MyFirstRepo$If you issue the 'ls' command again, you will see that we now have something inside our directory.
mccube@McSurface:~/devNetProjects/MyFirstRepo$ ls
MyVirtEnv
mccube@McSurface:~/devNetProjects/MyFirstRepo$Next, we need to activate this virtual environment. We can do this using the 'source' command following the path to the new virtual environment as a single line.
mccube@McSurface:~/devNetProjects/MyFirstRepo$ source MyVirtEnv/bin/activate
(MyVirtEnv) mccube@McSurface:~/devNetProjects/MyFirstRepo$Because my prompt is getting quite long at this point. I will remove everything up to the "/MyFirstRepo$"
(MyVirtEnv) mccube@McSurface:~/devNetProjects/MyFirstRepo$
becomes
.../MyFirstRepo$A Dirty little script
Making serious headway now!
Next, let's create a simple Python script. We won't bother with VSCode at the moment. We just need something quick and dirty for now.
We will simply echo a Python print command into a (currently non-existent) .py file.
Just to add a little extra content here. We are going to import the Cisco Meraki Library within the script. We will need to install this first using 'pip'.
.../MyFirstRepo$ pip install meraki
Collecting meraki
...[ Output Ommited ] ...
Successfully installed
.../MyFirstRepo$
.../MyFirstRepo$ echo "import meraki" > MyScript.py
.../MyFirstRepo$ echo 'print ("I am a Network Developer")' >> MyScript.py
.../MyFirstRepo$ ls
MyScript.py MyVirtEnv
.../MyFirstRepo$Look at that we now also have a script!
You can use the 'cat' command to have a look if the echo worked (but if the file exists, we can be pretty confident it did).
.../MyFirstRepo$ cat MyScript.py
import meraki
print ("I am a Network Developer")
.../MyFirstRepo$Pip Freeze
More like "Network Developer Legend" at this stage!
The reason we have added the Meraki Library is to help demonstrate something I came across quite frequently when first starting my DevNet journey.
When you get in to Github you will find that many of the programs you want to "clone" have a requirements.txt file. What even is this?
So, let's imagine that our script is a bit more fleshed out, and it requires that the meraki library has been installed (using pip like we did earlier)
When someone tried to use this script, if they do not have the requirements installed, it will naturally fail. A list of 1 requirement is easy but what if your script has dozens of these dependancies? A trick here is to have a requirements.txt file that the user can perform a 'pip -r install requirement.txt'
Now the requirements.txt file is nothin complicated, but it would be a pain if you had to write it out manually, so a fun trick here is the 'pip freeze' command (This is also another valid reason for having a virtual environment).
.../MyFirstRepo$ pip freeze > requirements.txt
.../MyFirstRepo$ cat requirements.txt
meraki==1.46.0
.../MyFirstRepo$Do not ignore gitignore
Great, we have a virtual environment, a script, and a requirements file.
The last thing I want to introduce here is a git ignore file.
To help emphasize this, let's first create a file called "secrets.txt". We will use this to store a password!
.../MyFirstRepo$ echo "MY_SECRET = madness-p@55w0rd" > secrets.txt
.../MyFirstRepo$ cat secrets.txt
MY_SECRET = madness-p@55w0rd
.../MyFirstRepo$ Remember, GitHub is a public place. The last thing you want to do is to give away your secrets in plain text.
This is why the use of a .gitignore file is so useful.
This is a hidden file that contains a list of files that should not be 'committed' to Git.
For us, this would be our virtual environment "MyVirtEnv" and the new "secrets.txt" file.
We can use 'echo' again to create the '.gitignore' file and append the names of the files/folders we want to exclude.
.../MyFirstRepo$ echo "MyVirtEnv" >> .gitignore
.../MyFirstRepo$ echo "secrets.txt" >> .gitignore
.../MyFirstRepo$ cat .gitignore
MyVirtEnv
secrets.txt
.../MyFirstRepo$Initialize Git
At this stage we are ready to Git going
We are in the final stages of this generic Git lesson.
Our new repo at this stage is nothing more than a directory. Git version control isnt actually in the mix yet.
To do this we need to initialise git within the directory.
.../MyFirstRepo$ git init
Initialized empty Git repository in /home/mccube/devNetProjects/MyFirstRepo/.git/
.../MyFirstRepo$Now it is initialised we can check the status.
.../MyFirstRepo$ git status
On branch main
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
.gitignore
MyScript.py
requirements.txt
nothing added to commit but untracked files present (use "git add" to track)
.../MyFirstRepo$We should hopefully notice our .gitignore file already at work. Notice how 'secrets.txt' is not in the list of currently untracked files? We are going to add these files using the 'git add .' command. Which will add all files to tracking.
.../MyFirstRepo$ git add .
.../MyFirstRepo$ git status
On branch main
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: .gitignore
new file: MyScript.py
new file: requirements.txt
.../MyFirstRepo$First Commit
Getting there. These files are tracked but not committed. To commit these to our local repository, we use the 'git commit' command along with a comment such as 'my first commit'
.../MyFirstRepo$ git commit -m "My first commit"
[main (root-commit) ebe2639] My first commit
3 files changed, 17 insertions(+)
create mode 100644 .gitignore
create mode 100644 MyScript.py
create mode 100644 requirements.txt
.../MyFirstRepo$With the files committed we are now tracking changes within them, This blog is already too long to go into branches. But hopefully you have picked up a couple things here to help you move forward.
Modifying the script
We have pretty much covered the majority of this blog, however we can also look into making a minor change and see how we can handle this.
Let's check the Git status again...
.../MyFirstRepo$ git status
On branch main
nothing to commit, working tree clean
.../MyFirstRepo$Everything is currently up to date. With no pending changes.
What happens when we add a single line to our existing script?
.../MyFirstRepo$ echo "print('I am a GIT master')" >> MyScript.py
.../MyFirstRepo$ cat MyScript.py
import meraki
print ("I am a Network Developer")
print('I am a GIT master')
.../MyFirstRepo$
.../MyFirstRepo$ git status
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: MyScript.py
no changes added to commit (use "git add" and/or "git commit -a")
.../MyFirstRepo$Intro to Git Diff
Git has recognised that the script file has bee changed. Git also has a 'diff' function that allows us to see these differences. I will add a little extra colour here to emphasise how the output is displayed.
.../MyFirstRepo$ git diff MyScript.py
diff --git a/MyScript.py b/MyScript.py
index 959fbb2..e63ab9e 100644
--- a/MyScript.py
+++ b/MyScript.py
@@ -1,2 +1,3 @@
import meraki
print ("I am a Network Developer")
+print('I am a GIT master')
.../MyFirstRepo$The output here is quite simple but looks a little scary if you have never seen it before. The first line (below) is simply letting you know it will be comparing files 'a' and 'b' (the old version (a) against the new version (b)).
diff --git a/MyScript.py b/MyScript.pyThe next two coloured lines are informational. It effectively indicates how you will be able to identity lines as they appear in the output.
Any lines with a minus (-) will be present in the old file but not the new.
Any lines with a plus (+) will be present in the new file but not the old.
Any lines with neither of these indicators are present in both files.
--- a/MyScript.py
+++ b/MyScript.pyWith this information we have have learned we can now start to turn our attention to the actual differences. In our script there isn't many. Both files contain the lines...
import meraki
print ("I am a Network Developer")but only the new file (b) contains the line
+print('I am a GIT master')A Second commit
If we are happy with this difference we can accept the new file by adding and committing.
This time instead of running the 'git add' and 'git commit' commands separately. We will perform both in a single line by using the 'git commit -a' variation.
.../MyFirstRepo$ git commit -am "Second Commit"
[main 0a459bc] Second Commit
1 file changed, 1 insertion(+)
.../MyFirstRepo$ git status
On branch main
nothing to commit, working tree clean
.../MyFirstRepo$And there we have it folks.
This was a long lab but hopefully has helped you in your git journey.
Comentarios