Git as a Network Engineer – Part 1

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.