In Part 1, we discussed why you should get started with Git as a Network Engineer and how to make your first commit. In Part 2, we will discuss how to get started with a Git server. In our example, to get started, we will utilize GitHub, as it is a free option. Most all of the same concepts apply to other Git servers as well, like GitLab, Gitea, etc. Keep in mind, though, that GitHub repositories by default are public, so anyone can view them on the internet. So be extremely careful what you put on them. Never store sensitive information in a public repository on any Git server systems. And even avoid saving it in private repositories whenever possible, as these systems are exposed to the internet. And there are vulnerabilities every day that could potentially be exploited to steal sensitive information. With that out of the way, on to using GitHub.

GitHub Account

For this blog we will assume you have an active GitHub account. If not, you will need to sign up for one. Once you are logged into GitHub, we will create a new repository. Make sure to enable multi-factor authentication (MFA) to make your account more resistant to hacking.

Create a Repository

Select the plus sign near the top of the page and select new repository. GitHub will then prompt you for a repository name, description, etc.

The repository name needs to be unique; description is optional. Select whether you’d like the repository to be public or private. If you were creating a brand-new repository for a project that hasn’t been started yet, it is simplest to have GitHub create at least the README.md file so you can clone the repo right away. In our case, since we have an existing Git repository on our local machine, we will not create a README.md, gitignore, or license file. Click on create repository.

When you don’t create the initial files using the repository create process, GitHub will provide you a couple of options to get existing code into the repository. We will use the second option, since we already started the Git repo locally. You will notice the url contains your username and the repository name. These are standard when working with GitHub, making it easy to find projects in a determinate way.

Create a New Local Repository and Link to GitHub

Back on your local system, we will create a README.md file by running the echo command with some text and use >> to pipe that into the README file. Then, we will initialize our working directory as a git repository using the git init command, and stage the changes we made to the README.md file. Then commit those changes to the Git history with the git commit command. Normally you would not need to use the -M parameter with the git branch command, but since the CLI git command sets the default branch to the name master, and GitHub sets the default branch to main unless you change it, that -M parameter forces a rename of the current local branch. We then add a “remote” to our repository, which is just the path to the repository on GitHub (or equivalent Git server). origin is the name of the remote that we created in the git remote add step, and main is the name of the branch we are pushing to. Lastly, we push our changes to the remote using the git push -u origin main (adding the -u parameter tells Git which named remote to use for a specific branch when you push or pull the repository).

echo "# blog" >> README.md
git init
git add README.md
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/zach/blog.git
git push -u origin main

Add an Existing Repository to GitHub

GitHub will also provide these commands to you if you create an empty repository, and it will be customized to your specific user/repository.

git remote add origin https://github.com/zach/blog.git
git branch -M main
git push -u origin main
Enumerating objects: 9, done.
Counting objects: 100% (9/9), done.
Delta compression using up to 10 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (9/9), 2.97 KiB | 1012.00 KiB/s, done.
Total 9 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (2/2), done.
To https://github.com/zach/blog.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

We now have the concept of a remote. This is the idea of a link to a remote Git server which hosts our code/files. You can actually connect a repository to multiple remotes to push code to multiple places, but that is beyond the scope of this blog. origin is the name of the remote and is just a standard convention for the main remote for a repository. This can be any name you want, though; you could call it github if that’s easier to remember. If you look back in GitHub now, you should see test.txt and file2.txt in the repository online.

Clone a Repository

Say you want to change computers and need to go back and get your code from GitHub, or you deleted the code from your computer. You would accomplish this through a process called “cloning” the repository. If you visit your repository on GitHub in a web browser, there will be a green button called Code near the top of the screen. Clicking this will open a drop-down menu with some options. You can clone a repository via HTTPS, SSH, or GitHub CLI. For now, we will use HTTPS—this is the easiest way. Using SSH involves setting up SSH keys and is beyond the scope of this document, but as you start working with private repos or would like verified commits, you will want to configure SSH. Cloning also works with public projects or other repositories you have access to. It’s basically just the act of pulling all the code from GitHub (or “Git server”) to your local machine. By default, it clones only the main/master branch.

Make Some Changes

We’ll create a new file in the main branch called file3 and commit that so we have something to work with when we go to push changes. We use the command touch on Linux/Unix systems to create a blank file, then edit the file using vim (you can also use nano/pico/etc). Then, we add ALL changes to be staged for commit by using the git add -A command. You can also use git add ., which stages only new files and modified files, but not deletions. As well as git add -u, which stages modifications and deletions, but not new files. You can also add individual files or directories by specifying those after git add. For example to include just this new file you would run git add file3.txt. The same goes for directories–just list the directory in the command to stage the directory and everything inside it. The most common action is git add -A since you will usually want to commit all your changes at once. We then commit those changes to the Git history using the git commit command, and give it an explanation of what we changed using the -m parameter.

$ touch file3.txt
$ vim file3.txt
$ git add -A
$ git commit -m "add file3.txt"
[main 24c3f53] add file3.txt
 1 file changed, 1 insertion(+)
 create mode 100644 file3.txt

Now we will discuss how to get these changes back to GitHub for permanent storage and sharing.

Private Repositories and GitHub Authentication

We need to address one thing prior to sending our changes to GitHub. GitHub requires the use of PAT for HTTPS as of August 13, 2021. Here’s more Information. This means that in order to make changes to a repository, you must be authenticated using a Personal Access Token, or SSH Key.

Now we’ll briefly discuss private repositories when working with GitHub. Private repositories should not be treated as 100% secure. Although access to them is restricted by credentialed access, this doesn’t prevent data leakage if the GitHub servers are hacked. There are a couple of different ways to work with private repositories with GitHub. The simplest is to generate a Personal Access Token that will be used to authenticate when cloning/pushing over HTTPS. Go into your GitHub profile, then settings, and scroll down to developer settings. Once there, you can create a token. You will want to adjust the permissions according to what you will need to do with the token. Be sure to always use least privilege access when setting the permissions, and use separate tokens for different services. For example, if you are going to place your repository onto a server that needs only clone/pull access, don’t give that token write access, since it doesn’t need it. Save this token in a password manager.

Once you have your token, you’ll be able to clone private repositories using your username and the token. You can test this by creating a private repository on GitHub and cloning it. When you do the git clone <repository_url>, you will be prompted to enter your GitHub username and the password, which is your Personal Access Token (PAT). With MFA enabled, your password will not work here; but the PAT will.

Push a Repository

Once we have our changes that we want to send up to GitHub, there are a couple of steps involved. Intuitively, Git has a command called push, which is used to upload to a remote Git server (in our case GitHub) the commits we made locally. If we run git push, we will see what happens.

$ git push
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 10 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 1.48 KiB | 1.48 MiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/zach/blog.git
   9c643a1..22e3ce9  main -> main

Now our changes are in GitHub, and others can see our changes. You can view these changes by viewing the repository in a web browser. You will also notice that you can see information from the most recent commits and who made changes.

Learning Git is an essential part of transitioning from a Network Engineer to an Automation Engineer. But did you know that it’s also extremely useful for the average Network Engineer as well?

Oftentimes people get nervous when we talk about DevOps, GitOps, automation, and similar topics. They say to themselves, “I’m not a programmer; I don’t need to know about any of this. I’ll stick with the CLI.” I can completely sympathise with these people, as there is a lot to learn when you start looking at configuration as code and automation; and it can be quite overwhelming. Learning Git is an essential step in a transition to being an Automation Engineer, but you don’t have to learn to program to benefit from a version control system. One thing to keep in mind, is that you don’t need something like GitHub to use Git. We’ll cover the difference between Git and a version control server later on. Documentation is a great place to start using Git where it’s simple, with no chance of breaking anything. How many times have you seen documentation in a Word document, and in the folder it’s stored in there are numerous copies of the same document named something like this:

Documentation v1.doc
Documentation v2.doc
Documentation - Final.doc
Documentation - Really Final.doc
Documentation - FINAL.doc
Documentation - Newest.doc

You can definitely tell which one of these is the current version, right? Okay, maybe you could look at last modified date or something like that, but it’s extremely confusing for new engineers, or even for yourself six months later when you try and remember what you did. Version control systems, like Git, solve this problem for you. While there are certain file types that work better with Git, you can use just about any type of text format within a version control system. Some common types of documents that work well are standard text files, markdown documents, and restructured text documents. By starting to learn Git using your current documentation system, you are able to start learning the concepts required for more advanced automation or programming positions, which makes finding changes so much easier.

First, let’s define a few terms we’ll be using throughout this series:

• Project/Repository – The folder that holds the files that you want to track with Git.
• Git history – Git’s internal tracking of all changes in a repository over time.
• Commit – The action of “saving” your changes to the Git history.
• Git server – Central server (or cluster of servers) where projects/repositories are stored.
• Remote – The URL/path of the repository on the Git server.
• Origin – The default name/reference to the remote for the project. Think the original location the files came from.
• Branch – Git uses tree analogies, and a branch is generally used to develop new features or changes without changing the default branch (usually called main or master).
• Clone – Make a local copy of a repository hosted on a Git server
• Pull – Pull down the latest changes from the Git server to your local copy.
• Push – Push local changes to a Git server.
• Merge – Applying changes from one branch to another. For example, your default branch is main, and you create a new branch called new_feature to do work on a new feature for your project. Once complete, you would merge new_feature into main to apply the changes you made in your branch into the main branch of the project.
• Fork – Taking a complete copy of a project. Usually used in open source projects where you want to take the project in a different direction than the creators originally intended. Also used in open source projects where you do not have write access to the original repository, you may have to fork a repository in order to have a copy you have rights to push changes to.
• Upstream – The original repository that was forked FROM.
• Pull Request (PR) – This is a concept with Git server where you’d like to merge some changes from a branch you are working on into the main branch of a project and you do not have merge rights on the repository. You open a pull request for the maintainers of the project to “pull” your changes into their main branch. It is also worth noting that some Git servers (GitLab for example) may refer this as a Merge Request, they are referring to the exact some item just different nomenclature.
• Gitignore – A file that can be used to list out files or directories that you do not want to track with Git.

If you’d like to follow along with some of the examples, you’ll want to install Git on your machine before reading any further. You can find the installation instructions here: Git.

Initial Configuration

The first basic configuration you will need to complete after Git is installed is telling it who you are. This information will be applied to your commits in order to identify who made a specific change. This is especially useful when you have a team of people all working on the same project. These values don’t necessarily have to be tied to anything, but it is useful when using a version control system like GitHub, as that information can be used to trigger notifications or other actions.

git config --global user.name <your_name>
git config --global user.email <your_email>

Once this information is set, we can create a new directory to house a test project to get a feel for the basic Git workflow. Make a directory called test, then open a terminal/command prompt inside that directory. Once inside the directory, look at the contents with ls -la (or dir on Windows). Notice the directory is empty.

{} test$ ls -la
total 0
drwxr-xr-x   2 user  root    64 Jun  6 13:48 .
drwxr-x---+ 74 user  root  2368 Jun  6 13:48 ..
{} test$

Now run git init

[main] {} test$ ls -la
total 0
drwxr-xr-x   3 user  root    96 Jun  6 13:49 .
drwxr-x---+ 74 user  root  2368 Jun  6 13:50 ..
drwxr-xr-x   9 user  root   288 Jun  6 13:49 .git
[main] {} test$

Congratulations, you just created a repository! You will now see that you have a folder called .git, where the . denotes a hidden directory. The contents of this folder aren’t important at this time, but just know it stores the “Git history” and information about the Git repository. You can also run git status for some information about the repository.

[main] {} test$ git status
  On branch main

  No commits yet

  nothing to commit (create/copy files and use "git add" to track)
  [main] {} test$

We see that we are on the main (this could also be master depending on your configuration) branch and we haven’t made any commits yet. That’s what we’ll do next.

First Commit

Now, we’ll make our first commit by creating a file called test.txt in your favorite editor.

[main x] {} test$ ls -last
total 8
drwxr-xr-x   4 user  root   128 Jun  6 13:54 .
drwxr-x---+ 74 user  root  2368 Jun  6 13:54 ..
drwxr-xr-x   9 user  root   288 Jun  6 13:52 .git
-rw-r--r--   1 user  root    16 Jun  6 13:54 test.txt
[main x] {} test$

We can see the new file test.txt in our directory. Now it’s time to add it to be tracked in Git and then commit the change to our Git history. Run git add -A (add all untracked files in the current path to Git). Then git commit. What should happen when you do git commit is your system will open the default CLI text editor and prompt you to enter a commit message. This short message should give some kind of indication of what was changed/added/deleted in the repository. In this case, “Initial commit” was used. This is a standard convention when creating a new Git repository after setting up the initial file structure. You can also do the commit message in the commit command by using git commit -m "<your_message_here>"

[main] {} test$ git add -A
[main] {} test$ git commit
[main (root-commit) 37504c6] Initial commit
  1 file changed, 1 insertion(+)
  create mode 100644 test.txt
[main] {} test

See the History

Now if you run a git log, you’ll be able to see the commits in the order they were performed on the repository and the commit message that was included. We can also see the commit hash, which is the long random-looking string in the first line. This becomes useful later on, when we discuss reverting changes to a repository.

commit 37504c659302b8853a40b74daf21fbd3db4d9fba (HEAD -> main)
Author: user <user@example.com>
Date:   Tue Jun 6 13:57:29 2023 -0500

    Initial commit

Reverting Commits

So now that I’m working with Git and creating commits as I make changes to my repository, I made a mistake in my last commit.

# original contents of test.txt
This is a test.

# current contents of test.txt after making some changes and commiting
This is NOT a test.

If I do a git log I can see that a change was made by “user” to make it “not a test”. We can see commits listed in reverse chronological order (most recent first).

commit ac2d6d6e75a3f9263c62a680d58f6dace396f8ca (HEAD -> main)
Author: user <user@example.com>
Date:   Tue Jun 6 14:13:54 2023 -0500

    Make it not a test

commit 37504c659302b8853a40b74daf21fbd3db4d9fba
Author: user <user@example.com>
Date:   Tue Jun 6 13:57:29 2023 -0500

    Initial commit

If I decide that it should not have been made “not” a test, I can just revert that commit to go back to how it was before by specifying the commit I want to revert to. You can do this for any commit in the history, but be aware if you jump back multiple commits, all those in between get reverted as well. So if we run git revert ac2d6d6e75a3f9263c62a680d58f6dace396f8ca, the CLI will prompt for a new commit message and usually autofill something like “revert” where commit_message is whatever the commit message originally was on that commit. After saving the commit message, we can reopen the file and see the contents have been reverted back to the original text.

# original contents of test.txt
This is a test.