Authors: Luke Rawlins
TLDR; git is awesome. It will save you time, and headaches if you are working on automation.
Recently I’ve put some serious effort into learning and using git for version control.
I know what you’re thinking…. probably something like “Just now learning git? Have you been living under a rock?”… I realize that I’m at least 10 years late to this party I just didn’t know what I was missing.
My version control system of choice prior to a few weeks ago involved a process that is probably familiar to some of you, who like me, find yourself doing things the hard way, for way too long.
If I was working on modifying a script, I would simply make a copy of it and call it something like
. In all honesty, this process has worked just fine for most of my life. I’m not a coder by trade, I’m an operations guy, so most of my scripts were only a handful of lines, and most of those only performed boring tasks that I could do manually for awhile if I absolutely had to. No work really stopped if I had to spend a couple of days fixing a broken script it would just slow down a bit.
So what changed? Anisble
Over the last couple of years, Ansible has taken a huge foothold in my daily work life. We use it for pretty much everything, in a lot of ways Ansible has become the way Linux administration is done around my office. As a result, the old way of renaming a file, and moving playbooks to a new directory had become completely unsustainable. We would quite literally have dozens of directories with playbooks in various states of disarray, that would quickly become abandoned when a new change was required and we had to cut over to yet another new directory of playbooks. God help you if you mess up the blessed version of any roles used for deployments, configuration, or patching! Gone are the days when that would just mean work slows down for a bit while the scripts are fixed. Quite literally work would come to a grinding halt (for some things anyway) until the problematic playbooks are fixed. The Ansible playbooks have begun to do so much of the heavy lifting especially around server deployment and patching that if those playbooks were to break, we simply do not have the staffing resources to manually do all that work, it would be impossible to keep up with it all. This is where git comes in.
Absolutely everything… Well, everything that involves modifying plain text files, which in Linux is pretty much everything. Git comes with a feature called branching. Branching means that you can take all the things in your current working directory, modify them on a “branch” without changing the “master” copy and then merge those changes into the master branch when you are ready. These branches are created nearly instantly, they are easy to switch to, and they will change your life if you used to manage the files the way I did.
The git documentation (git-scm documentation) describes branching like this:
Branching is the feature that got me hooked on git. It means that my workspace can be cleaner. I don’t have to worry about orphaned files laying around that may or may not be useful. I simply create a new branch start working on a fix, or a new feature and then delete that branch after I’ve merged the changes. Nothing to clean up, nothing half-broken laying around waiting for some poor unsuspecting soul to run accidentally. Try
git checkout -b dev
after you initialize your first test repository. If you haven’t used git I’m sure you will be just as impressed as I am.
You don’t have to create a git hub account, or even build new infrastructure to start using git. This one of the big misconceptions I had around git. I assumed you needed a remote repository of some sort in order for it to work, you don’t. Git is designed to run just as well locally as it does from a remote.
With Git, nearly all operations are performed locally
Git definitely makes it easy to share code if that is what you want to do, but that is not its primary purpose. First and foremost it is a version control system, and it excels as a strictly local repository for your files. No GitHub required, no new accounts to keep track of.
Installing git on any operating system is easy, and after learning a few core commands you can start to use git on your local system to maintain code (or blog posts), or Ansible playbooks. All without generating a bunch of orphaned files that you aren’t sure whether or not it’s safe to delete. Installing git is so easy that I’m not even going to bother going over the installation here, in some cases, your OS might already have git installed. If you are ready to try git for yourself head on over to https://git-scm.com/book/en/v2/Getting-Started-Installing-Git you will quickly find how to install git on Linux, macOS, and Windows.
I’m sure some of you have been using git for years. Please share anything that you’ve learned along the way. If you are new to git and decide to try it out, let me know how it goes.
If you’d like to get in touch, contact with me via email.