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.

Why bother?

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 "user@email.com" 

First Repo

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.

Git Add

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.

Git Commit

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. 

Change tracking

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.

Link Get Started with Git Remote