Git with the program

By: Luke Rawlins Feb 23, 2020 | 6 minutes read
Share this:

Tags: ansible, git, version control

**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.

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.

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.

With Git, nearly all operations are performed locally > > [https://git-scm.com/about/small-and-fast](https://git-scm.com/about/small-and-fast)

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.

Related Posts


Force Local Users and Groups with Ansible

I’m in the process of migrating a few Puppet modules over to Ansible, and in the process I’ve run into an unusual situation while creating users and groups. Here is some background. I have an application that will refuse to complete its installation unless it can see certain users and groups in the local passwd and group files. It just so happens that these same users and groups are also contained in LDAP. Read more

How to get started using Ansible

Install Ansible On most Linux distributions Ansible can be installed directly through your distribution’s package manager. For those using macOS or a distribution that doesn’t package Ansible, you can install it via python pip. The Ansible docs have a really good walkthrough for installation that can be found here:http://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html I won’t repeat those instructions except to say that you will want to make sure that the computer you install Ansible on should have Python 2. Read more

Three reasons to start using Ansible

A few months ago I attended a one day Ansible workshop in Columbus Ohio with a colleague. The workshop was sponsored by Red Hat and contained several labs, which is well worth your time if you have the opportunity. I wasn’t sure what to expect, generally you don’t walk away with much working knowledge from these short events, but I had some experience with Puppet (most of it frustrating) and I was curious to see what Ansible could do for my organization. Read more


Contact

If you’d like to get in touch, contact with me via email - or follow on Twitter.

editor@sudoedit.com