6 minute read

Introduction to Git and GitHub

In my inaugural post about The Four Stages of Automation (or was it 5?), Git was mentioned in passing, and I figured I finally owed you a post about it since it’s central to much of coding and automation, at least if you want to use open-source software (OSS) and/or give back to the community by sharing the things that have worked for you. In writing this post, I quickly realized that there is so. much. Git. Even limiting the scope to lab/containerized nautobot deployments, it was still way too long for a single post, so we’re going to call this Part 1, link to the rest of what I have so far in Part 2 and continue whenever there is time to add more.

To start with, though, let’s be clear about something that causes a lot of confusion among the uninitiated, and that is the difference between Git and GitHub:

Git
The version-tracking application (usually CLI-based) used on the local machine (also: git).
GitHub
The webserver that serves as the central storehouse for many different repos around the world; in Git, it’s referred to as the “remote” or “origin” for a particular repository.
There are many repository-hosting alternatives to GitHub, such as GitLab and Gitea

If you don’t quite get all these terms, don’t worry about it, we’ll get there. The main thing to understand is that Git is local, GitHub or similar is remote.

Some History

At some point in the 70’s or 80’s1, developers on mainframes got tired of not being able to figure out when bugs were introduced (or losing their work entirely due to an accidental rm -rf) and came up with the idea of version control. Initially, this was just applied to individual files on a local system which every stakeholder would log into, like a shared Unix machine, and the files could be anything made up of text, like C code or a backed-up router config.

Ye olde RCS version control file, Cisco config, circa 2003

These files were fairly primitive, sometimes storing the changes (a.k.a. “deltas”) directly in the file even, but usually with a way to see who made each change and when. If the single system crashed or was corrupted, however, users stood to lose everything they’d created, and there were other drawbacks such as difficulty working in parallel with others on the same file.

As time went on, improvements appeared, such as the client-server model, the concept of a repository, which is a collection of related or dependent files, and the concept of branching, which allowed users to work on development code in parallel with each other as well as the working “trunk” version of released code. Perhaps the most disruptive innovation, however, was the concept of the fully-distributed version control system. There are apparently many open-source packages nowadays that fall under this umbrella, but the most famous and widely-adopted by far has got to be Git, for better or worse.

Created by Linus Torvalds for use on the Linux kernel project, he joked that he came up with the name by naming “all my projects after myself. First ‘Linux’, now ‘git’”. Perhaps more importantly, he conceived of the idea of cloning, which means that:

“every Git directory on every computer is a full-fledged repository with complete history and full version-tracking abilities, independent of network access or a central server.” – Wikipedia

And thus it is said to be fully distributed. But what does this have to do with network automation, and you? For those using OSS packages, more often than not they will have to be cloned from a Git server such as GitHub or Gitlab. And even for those not using OSS to automate, some sort of version control is usually a good idea if you don’t want to risk losing changes or have others’ changes overwrite working files in general.

Cloning Repositories in Git

So, regarding installing OSS packages, developers usually create install instructions on the main GitHub page of the repository, called “README.md” in the repo files. It generally involves cloning the repository to a directory on your local machine, for example:

git clone https://github.com/nautobot/demo-gc-backups

Cloning a repo like this on a unix-like command line will copy all the files from GitHub to a directory on the local machine named demo-gc-backups in this case (“nautobot” here is the organization name).

Make sure you are not cloning the repo into a directory that is also a git repo (one that has a .git file in the root).

If you cd to that directory, you’ll find all the working text files (like router configs, or code, depending on the repo), a .git file, plus maybe a few other special git files such as .gitignore. You can then follow the dev’s instructions in the README to use the package, or click through to any linked documentation.

If you’re not sure how to find the URL of the repo, copy it from the URL bar in your browser or use the green “<>Code” button as seen in Step 3 of Creating Repos.

If using others’ OSS packages is all you want to do, you can probably stop reading. But if you want to use Git for your own version control (a.k.a. Source Code Management or SCM), you’ll probably want to start with a tutorial, especially if this is your first introduction or you’re stuck on something. There is way more detail to interacting at that level with Git and GitHub than I could hope to cover here and still maintain an automation focus, even after splitting the post into multiple parts.

Git Tutorials

As far as tutorials go, up until recently I’d generally recommend git-scm to new users. On the Network To Code slack not too long ago, however, someone asked experienced users for their recommendations on this topic and ended up with a treasure trove of answers, so pick the one that works best for you:

Tinker Toys - who'd have thought? Oh right, Michael Schwern did in 2013.
  • Pro Git (the above git-scm material, but it’s a book)
  • Git for Ages 4 and Up (YouTube video where Tinker Toys stand in for Git concepts)
  • Git 101 - Infrastructure as Code
  • Learn Git Branching (fully dynamic terminal in your browser)
  • Git for Network Engineers
  • Advanced Git Tutorial (YouTube)
  • There is one other with a less conventional title that we’ll leave googling as an exercise for the reader if they are so inclined, as this is a professional blog and I don’t want to assume what gets a pass at your place of work. It’s along the lines of “Oh no, git!”, can be found on wizardzines.com, and the subtitle is “Recipes for getting out of a git mess”. Naturally, it had the most positive reactions (4) on the slack thread, though they were all from the same person. I did download it and found it to be pretty helpful, as long as the title doesn’t scare you away and you’re good with handwriting font and stick drawings.

Creating Your Own Repos For Automation

Since this blog is mainly focused on automation, I’m going to assume you’re here to find out how to use repos for things like Golden Config (GC) or other SSOT applications, or perhaps you have created some automation scripts you want to share with the world. You may also want to contribute a bugfix or some documentation to an OSS project you’ve used. This series will cover the ins and outs of all these scenarios (and maybe more) in later posts. At this point, that means we’ll go over:

But of course this could change over time as the posts evolve. Happy automating!


  1. Nope, it’s not a reference to the commit history–it’s actual history. Sorry to disappoint the git veterans. 

Categories:

Updated: