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. Now, 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 “newscript-v2” or “somescript-test”. 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.
Git-huh what is it good for?
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:
- Frictionless Context Switching. Create a branch to try out an idea, commit a few times, switch back to where you branched from, apply a patch, switch back to where you are experimenting, and merge it in.
- Role-Based Codelines. Have a branch that always contains only what goes to production, another that you merge work into for testing, and several smaller ones for day to day work.
- Feature Based Workflow. Create new branches for each new feature you’re working on so you can seamlessly switch back and forth between them, then delete each branch when that feature gets merged into your main line.
- Disposable Experimentation. Create a branch to experiment in, realize it’s not going to work, and just delete it – abandoning the work—with nobody else ever seeing it (even if you’ve pushed other branches in the meantime).
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 devafter you initialize your first test repository. If you haven’t used git I’m sure you will be just as impressed as I am.
Git runs locally
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. It is designed to run just as well locally as it does from a remote.
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 is trivial
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.
Some resources to help you get started.
- The free ebook: https://git-scm.com/book/en/v2
- I have read this nearly cover to cover and cannot recommend it enough. This is an excellent resource.
- The docs: https://git-scm.com/docs
- rtfm noob
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.