I spent most of my time in IT as a system admin, on the “Ops” side of DevOps. Over the years, I have accumulated many different batch files and scripts of one type or another. File shares worked well for storing the code I write. I discovered Git and it’s become my main repository for all script related code. Recently, I attempted to make a case to other admins for using Git, but failed to make a convincing case. Below, I lay out my case to why a sysadmin or anyone writing any kind of script should move to Git. I also outline how I use it in an effort to make my case and help anyone interested in getting started with Git.
What is Git?
Git is a free, efficient, and local version control system. It allows for distributed collaboration. Files are edited locally and changes sent to a central repository. If you spend some time researching the topic online, it’s easy to get bogged down in branching and forking and remote pushes. Don’t get caught up in that. Odds are you don’t have multiple developers working on scripts (but if you do, Git will support that also). Let’s focus on free, local and version control for now.
At the heart of Git is a version control system with commented commits. File systems have backups (sometimes), but that doesn’t track significant changes made during editing and testing scripts. Reverting back to a version changed multiple times during a day may not be possible unless you made copies of the file along the way. That’s inefficient and keeping track of the version will become impossible after a while.
When code is stored in an online or internal repository such as GitHub and GitLab, it can be called from the online source and ran without being stored locally. This is useful for cloud-config files such as JSON templates or Terraform files. This also makes a case for Git and its role in DevOps.
I have also found that some organizations lock down USB drives or cloud storage such as OneDrive and Dropbox, making portability difficult. Most allow access to GitHub.
The last reason to move to Git is that it’s cool. Not a good enough reason? Over the past 20 years I have seen (or been part of) sysadmins buying a lot of crazy stuff because it’s cool. So, don’t discount the cool factor.
How does it work?
Some of you may have experience with a code repository like Team Foundation Server. The code is kept on the server, checked out, modified and checked in. That’s not how Git works. Git is local, no server is needed. You only need the Git application installed on a local machine to use it.
Git stores data in a hidden folder in the same directory as the files, this becomes the root of the repository (repo). One simple command, git init (for initialize) sets up the Git repo (I walk through this process below). This command enables all files and subfiles to be part of the repo.
Once git init is ran, it’s time to create some content. Edit and save scripts to the folder. At some point you are going to have a version you want to keep for prosperity. Maybe an official version or just a version that working and you want to create a checkpoint before moving on. Now it’s time to put Git to work. To create that checkpoint, I need two commands, git add and git commit.
The first command, git add, adds the file to the index, but does not update anything. It only adds the files to be committed in the next step.
Now the file has been added, Git knows about it, but it hasn’t been “cheeked in”. to do that, I run the git commit command. This command commits the file to Git, creating a checkpoint. The git commit command has a required comment or message “-m” used to track the commit. It may be tempting to put something simple like “update”, “check-in”, or “blah, blah, blah”, but don’t. The reason you have read this far is that you see value in tracking changes to your scripts. Add something meaningful for future reference.
That’s it; git init, git add and git commit will take you 95% of the way with Git. There is more, a lot more. I intend to cover integrating Git into editors such as VSCode and online repositories in upcoming posts. But first, lets setup Git and create a repo.
Set up Git
The first step is to download and install Git. There are two options, a GUI client and a Bash version. I recommend and will be using the Bash version. The GUI client has a lot of features that I haven’t used. The Bash version is more universal, working the same no matter the platform it’s running on. Download the version for your OS from here https://git-scm.com/downloads and run the installer.
All options can be left as default. The only one you may want to change is the default editor used by Git. It’s set to Vim by default, changed it to something different if you would like.
You should see some Git options on the start menu. Run Git Bash to get started. From the prompt, run git version to verify it’s working.
Congratulations, you now have Git installed. Before I move on, let’s give Git our user information. Do this with the two commands below to assign your user name and email address. These will be used to track who is making changes, not that critical in an environment of one, but important as I move along.
Git config --global user.name “user name” Git config --global user.email "firstname.lastname@example.org"
Now for the fun part. Create a folder on your computer, I’ll create a folder called First Repo under my documents for this demonstration. Create a text file in the directory. The name is not important, I called mine test.txt. I also added a single line of text to give it a little content.
Save the file and go back to Git Bash. Now that I have a little content, let’s initialize the repo. This is done with the git init command.
git init “C:\Users\Administrator\Documents\First Repo”
Alternatively, you could run the git init command from the directory without the path.
You have now created a Git repo. Go back into the folder and if Windows Explorer is set to default, you won’t notice anything different. However, if you enable view hidden items, you should see a new hidden folder named .git. This is where Git does its work. There is a lot going on in this folder, but I’m focusing on how to use Git, not how it works. For now, it’s sufficient to know this is where all the indexing information is stored for this repo.
Now the repo is set up, next I add or stage a file to it. I moved into my repo directory so I don’t need to append the path to commands. I ran the git ls-files command and it returns nothing because, well, I haven’t added anything. The git status command confirms that my file, test.txt is not tracked. It even tells me how to add it.
Next, the file is added to Git. Run the git add command to add the file.
git add test.txt
Once ran, the git status command shows a file added but not committed.
The file is committed with the git commit command. This creates a checkpoint in the Git index used for tracking changes. The command requires a message for the commit. This is the comment used to identify what changed, or the significance of the commit. The best practice is to put something meaningful in the message. After all, there is no point in tracking changes if the only notes on the change are “updated files” or “checked in”.
git commit -m “initial commit”
The file has now been committed. Running the git status command shows updated information. Also, the git ls-files now show the file added to the repo.
Did a text editor open when running a commit? That means you left off the -m “comment”. It’s telling you it needs a comment and kindly opened a text editor so you can do so. Enter a comment and save to continue. If you find yourself stuck in Vim, hit the Esc key, then colon : and type q!, press enter.
To illustrate the change tracking ability of Git, I first need to change the file. I added some test to my test file and saved it. Next, I run the git add and git command again as I did before.
The commit history is displayed with the git log command as shown below. Now you can see how all the work so far has paid off. The output shows who made the changes, at what time and gives the comment information.
This is all good, but what if you want to look at one of those previous versions? That is easy to do with the git show command. The git show command requires the hash value (shown after commit in the image above) and the path to the file. Below shows the output from both of my commits along with the content of the file.
git show <Commit Hash>:file/path
Is it worth it?
When I first started using Git it seemed like a lot of extra steps. It may seem redundant to have to do a git add and a git commit to commit the file, but it makes sense if the directory has a lot of files. The git add command provides the ability to selectively add files.
Keep in mind, the whole process is much easier with a code editor that has Git integration. Also, pushing changes to a central repository keeps a copy in a secure offsite location. That’s safer than a USB thumb drive!
To return to my original motive, Git provides:
- Efficient commented version control
- Local and Free
- Sync to secure off-site hosted repositories (and GitHub is free)
- It’s cool
That makes it worth it for me!
Now that I’ve covered the basics, coming soon is using Git with a VSCode and a remote repository.
5 thoughts on “Git for System Admin Scripting”
The one point you didn’t address that will ultimately seal the deal, and likely the biggest question on the minds of the sysadmins: But how do I browse the previous versions of a file? There is a huge disconnect in the develop mindset and sysadmin mindset when it comes to commit tracking. Sysadmins just see superfluous tracking data that prevents them from easily opening several previous versions simultaneously.
It was a very helpful tutorial. Almost all points are covered in this tutorial which are relevant from the sysadmin’s point of view.
However the one thing which is not covered in this tutorial. That is, how can we go back to the previous version of the file or to any specific commit?
To answer the first two comments, there is a page here (https://stackoverflow.com/questions/338436/how-can-i-view-an-old-version-of-a-file-with-git) that explains how to do what you ask from the git command line. If you’re anything like me, you came from a Windows background and you’re looking for something a bit more “mouse-friendly.” Thankfully, there are a few solutions that meet that criteria …
First, if you’re willing to store your code in the cloud, then you can push your local code to GitHub (or some other Repo tool such as Azure DevOps or Azure Repos). Once your code is in the cloud, you just view it in a browser, which quickly exposes each commit. Once you go to the commit that has the changes you need to view, you’ll be able to click on the code file and it will open right there in your browser.
The other great option is to use Visual Studio Code (sometimes called VSCode). You install it on your local PC, and then you can use it to manage your code stored on the local PC. (But it can also be used with remote repos such as GitHub or Azure DevOps – so if you start with just local code and eventually decide to store the code in the cloud at a later date, you can do that too.)
So those are three ways to access your previous versions of files.
I come from a SysAd background myself, and for the last two years have been working almost exclusively managing Azure DevOps Server and Azure DevOps. As I began to see how developers were managing their code, it became clear that I needed to move my scripting into a source control system. So I’ve actually moved to using VSCode as my day-to-day text editor. I’ll admit there was quite a learning curve, and I’ve shouted at my screen more than a few times during the transition! But there is a lot of help on Youtube and other online sources. Travis has a really good video on how to setup VSCode to work with your Azure DevOps repos at this link (https://www.youtube.com/watch?v=8ER87ePdoCU).
Pingback: Using VS Code with Azure DevOps Git Repos - Firnco
Pingback: The use of VS Code with Azure DevOps Git Repos - Firnco