Transitioning from a traditional network engineer to an automation engineer can come with a steep learning curve. Terms like git, merge, squash, branch, and rebase can be daunting. While there are many “getting started” tutorials out there for git, it feels like most of them are geared toward programmers and those who have team members that they can reach out to for help learning git. In a lot of cases there’s already an established git workflow that new employees follow to move their code into the codebase, so they can get started by just following the workflow that someone else built without even knowing what each of the pieces does. Usually as a network engineer trying to move into the automation space, there’s no such team or workflow to rely on, so you’re stuck learning on your own. This post will aim to dispell some of the mysteries around git and why you should use it. We will address basic git for network engineers and how you can benefit from learning git on your automation journey. Keep in mind this blog is meant to be just a high level overview of git and how to use it in the most basic fashion. Some of the conventions or methods use here might not be best practices when using git in a real-world environment, but it should be enough to get you off and running. Every organization has a little different git workflow and it would be impossible to cover all that here. On that note, let’s get started.
Firstly, why do I need git? While the answer might be obvious to some, let me paint a picture for you. You are a network engineer who has recently learned about automation and you have started working with something like Python or Ansible. You start off by creating an Ansible playbook that reboots some Cisco switches. The playbook might look something like what’s below:
---
hosts: switches
gather_facts: false
tasks:
- name: reboot ios device
cli_command:
command: reload
prompt:
- Save?
- confirm
answer:
- y
- ySimple playbook right? Maybe you have to edit it a couple of times to get it working correctly, but easy to have one version and make some changes, and keep everything straight. Now, you want to add some functionality to this and have it upgrade the IOS version before it reboots. For brevity I’ll just post a link to the code vs trying to paste it all here: https://github.com/bile0026/cisco_updates This is a pretty simple Ansible role with a handful of tasks. Now we are talking multiple files and an entire folder structure of items that might need to be tweaked, adjusted, or updated as you troubleshoot and improve the job to do more validation, making sure the device is back online after the upgrade, etc… What most of us have done in the past was to keep versions in their own folders, so then you end up with something like this each time you make an update that works so you can always go back.
cisco_updates cisco_updates_V2 cisco_updates_final cisco_updates_really_final cisco_updates_FINAL
You get the idea. How are you supposed to remember what changed from version to version or even try and keep track of which one should actually be used. This gets especially confusing when there’s another person that’s trying to help you or use these playbooks. Hopefully you can start to see the issue with this approach.
Git, not to be confused with GitHub is one of a few version control systems (VCS) that are commonly used in the software industry. Lesser-known options like subversion and mercurial also accomplish a lot of the same goals, but git seems to be the most popular. VCS does exactly what it’s name implies. It manages versions of the files that it manages and allows a user to easily see what has changed in a given project over time and easily revert changes if a new change breaks the application. This same methedology applies to automation jobs and playbooks that we write as automation engineers. A project doesn’t have to be overly complex to benefit from using a VCS like git. One of the simplest things you can start using git to manage is documentation. This is where I started out when first learning git, and it made the process much easier. Since all the files were literally text files or markdown (formatted text) there was no code to worry about to complicate the learning.
Back to git vs GitHub (or GitLab, Bitbucket, etc) for a minute. One of the cool things about git is that it can actually be used locally on your machine without ever connecting to a server to do version management for all your local projects. This can help you to manage local projects without the complexity of managing credentials or online-accessible storage where security can be a concern. Git can also be used with a git server like GitHub to provide a central place to store all the files and history of what has happened throughout the project. This has the added benefit of being about to not only have a single place for backups and accessing your projects, but it makes it far more simple to share your projects with others. Git can be used from the CLI or from within various graphical clients like GitHub desktop, gitkraken, or VSCode.
There’s a few terms we will use in this basic introduction to git and we will define those here:
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.
Origin – The default name/reference to the remote for the project. Think the original location the files came from.
Remote – The url/path of the repository on the git server.
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 originially 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.
Gitignore – A file that can be used to list out files or directories that you do not want to track with git.
Now you should have a good idea why you should be using git and have at least some idea why it could be useful for you. In Part 2 of this series, we will discuss how to get started actually using git and creating your first repository.
One thought on “Git for Network Engineers – Part 1”