{"id":1368,"date":"2019-10-12T02:07:15","date_gmt":"2019-10-12T02:07:15","guid":{"rendered":"https:\/\/www.ciraltos.com\/?p=1368"},"modified":"2023-03-23T22:56:19","modified_gmt":"2023-03-24T03:56:19","slug":"git-for-system-admin-scripting","status":"publish","type":"post","link":"https:\/\/www.ciraltos.com\/staging2\/git-for-system-admin-scripting\/","title":{"rendered":"Git for System Admin Scripting"},"content":{"rendered":"\n
\"Git\"<\/figure>\n\n\n\n

I spent most of my time in IT as a system admin, on the \u201cOps\u201d 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\u2019s 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.  <\/p>\n\n\n\n\n\n\n\n

What is Git?<\/h2>\n\n\n\n

Git is a free, efficient, and local version control system. It\nallows for distributed collaboration. \nFiles are edited locally and changes sent to a central repository.  If you spend some time researching the topic\nonline, it\u2019s easy to get bogged down in branching and forking and remote\npushes.  Don\u2019t get caught up in\nthat.  Odds are you don\u2019t have multiple\ndevelopers working on scripts (but if you do, Git will support that also).  Let\u2019s focus on free, local and version\ncontrol for now.<\/p>\n\n\n\n

Why bother?<\/h2>\n\n\n\n

At the heart of Git is a version control system with\ncommented commits.  File systems have\nbackups (sometimes), but that doesn\u2019t track significant changes made during\nediting and testing scripts.  Reverting\nback to a version changed multiple times during a day may not be possible\nunless you made copies of the file along the way.  That\u2019s inefficient and keeping track of the\nversion will become impossible after a while. \n<\/p>\n\n\n\n

When code is stored in an online or internal repository such\nas GitHub and GitLab, it can be called from the online source and ran without\nbeing stored locally.  This is useful for\ncloud-config files such as JSON templates or Terraform files.  This also makes a case for Git and its role\nin DevOps.<\/p>\n\n\n\n

I have also found that some organizations lock down USB\ndrives or cloud storage such as OneDrive and Dropbox, making portability\ndifficult.  Most allow access to\nGitHub.  <\/p>\n\n\n\n

The last reason to move to Git is that it\u2019s cool.  Not a good enough reason?  Over the past 20 years I have seen (or been\npart of) sysadmins buying a lot of crazy stuff because it\u2019s cool.  So, don\u2019t discount the cool factor.  <\/p>\n\n\n\n

How does it work?<\/h2>\n\n\n\n

Some of you may have experience with a code repository like\nTeam Foundation Server.  The code is kept\non the server, checked out, modified and checked in.  That\u2019s not how Git works.  Git is local, no server is needed.  You only need the Git application installed\non a local machine to use it. <\/p>\n\n\n\n

Git stores data in a hidden folder in the same directory as\nthe files, this becomes the root of the repository (repo).  One simple command, git init<\/em> (for\ninitialize) sets up the Git repo (I walk through this process below).  This command enables all files and subfiles\nto be part of the repo.  <\/p>\n\n\n\n

Once git init<\/em> is ran, it\u2019s 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\u2019s time to put Git to work.  To create that checkpoint, I need two commands, git add<\/em> and git commit<\/em>.<\/p>\n\n\n\n

The first command, git add<\/em>, adds the file to the\nindex, but does not update anything.  It\nonly adds the files to be committed in the next step. <\/p>\n\n\n\n

Now the file has been added, Git knows about it, but it hasn\u2019t been \u201ccheeked in\u201d. to do that, I run the git commit<\/em> command.  This command commits the file to Git, creating a checkpoint.  The git commit<\/em> command has a required comment or message \u201c-m\u201d used to track the commit.  It may be tempting to put something simple like \u201cupdate\u201d, \u201ccheck-in\u201d, or \u201cblah, blah, blah\u201d, but don\u2019t.  The reason you have read this far is that you see value in tracking changes to your scripts.  Add something meaningful for future reference.  <\/p>\n\n\n\n

That\u2019s it; git init,<\/em> git add<\/em> and git commit<\/em>\nwill take you 95% of the way with Git. \nThere is more, a lot more.  I\nintend to cover integrating Git into editors such as VSCode and online\nrepositories in upcoming posts.  But first,\nlets setup Git and create a repo.<\/p>\n\n\n\n

Set up Git<\/h2>\n\n\n\n

The first step is to download and install Git.  There are two options, a GUI client and a Bash\nversion.  I recommend and will be using\nthe Bash version.  The GUI client has a\nlot of features that I haven\u2019t used.  The\nBash version is more universal, working the same no matter the platform it\u2019s\nrunning on.  Download the version for\nyour OS from here https:\/\/git-scm.com\/downloads<\/a>\nand run the installer.<\/p>\n\n\n\n

All options can be left as default.  The only one you may want to change is the default\neditor used by Git<\/em>.  It\u2019s set to Vim\nby default, changed it to something different if you would like.<\/p>\n\n\n\n

\"\"<\/a>
Git Default Editor <\/figcaption><\/figure>\n\n\n\n

You should see some Git options on the start menu.  Run Git Bash<\/em> to get started. From the\nprompt, run git version to verify it\u2019s working.<\/p>\n\n\n\n

\"\"<\/a>
Git Version <\/figcaption><\/figure>\n\n\n\n

Congratulations, you now have Git installed.  Before I move on, let’s give Git our user\ninformation.  Do this with the two\ncommands below to assign your user name and email address.  These will be used to track who is making\nchanges, not that critical in an environment of one, but important as I move\nalong.<\/p>\n\n\n\n

Git config --global user.name \u201cuser name\u201d\nGit config --global user.email \"user@email.com<\/a>\" <\/pre>\n\n\n\n
\"\"<\/a>
  User Name and Email  <\/figcaption><\/figure>\n\n\n\n
First Repo<\/h2>\n\n\n\n
Now for the fun part. \nCreate a folder on your computer, I\u2019ll create a folder called First\nRepo<\/em> under my documents for this demonstration.  Create a text file in the directory.  The name is not important, I called mine test.txt<\/em>.  I also added a single line of text to give it\na little content.<\/p>\n\n\n\n
\"\"<\/a>
 First Git File <\/figcaption><\/figure>\n\n\n\n
Save the file and go back to Git Bash.  Now that I have a little content, let\u2019s\ninitialize the repo.  This is done with\nthe git init<\/em> command.  <\/p>\n\n\n\n
git init \u201cC:\\Users\\Administrator\\Documents\\First Repo\u201d<\/pre>\n\n\n\n
Alternatively, you could run the git init<\/em> command\nfrom the directory without the path.<\/p>\n\n\n\n
You have now created a Git repo.  Go back into the folder and if Windows Explorer\nis set to default, you won\u2019t notice anything different.  However, if you enable view hidden items<\/em>,\nyou should see a new hidden folder named .git. \nThis is where Git does its work. \nThere is a lot going on in this folder, but I\u2019m focusing on how to use\nGit, not how it works.  For now, it\u2019s\nsufficient to know this is where all the indexing information is stored for\nthis repo.<\/p>\n\n\n\n
\"\"<\/a>
 Git Hidden Folder <\/figcaption><\/figure>\n\n\n\n
Git Add <\/h3>\n\n\n\n
Now the repo is set up, next I add or stage a file to\nit.  I moved into my repo directory so I don\u2019t\nneed to append the path to commands.  I\nran the git ls-files<\/em> command and it returns nothing because, well, I haven\u2019t\nadded anything.  The git status <\/em>command\nconfirms that my file, test.txt<\/em> is not tracked.  It even tells me how to add it.<\/p>\n\n\n\n
\"\"<\/a>
 No File Added <\/figcaption><\/figure>\n\n\n\n
Next, the file is added to Git.  Run the git add<\/em> command to add the\nfile.<\/p>\n\n\n\n
git add test.txt<\/pre>\n\n\n\n
Once ran, the git status <\/em>command shows a file added\nbut not committed.<\/p>\n\n\n\n
\"\"<\/a>
 Git Add Command <\/figcaption><\/figure>\n\n\n\n
Git Commit<\/h3>\n\n\n\n
The file is committed with the git commit<\/em>\ncommand.  This creates a checkpoint in\nthe Git index used for tracking changes. \nThe command requires a message for the commit.  This is the comment used to identify what\nchanged, or the significance of the commit. \nThe best practice is to put something meaningful in the message.  After all, there is no point in tracking\nchanges if the only notes on the change are \u201cupdated files\u201d or \u201cchecked in\u201d.  <\/p>\n\n\n\n
git commit -m \u201cinitial commit\u201d<\/pre>\n\n\n\n
\"\"<\/a>
 Git status Command
<\/figcaption><\/figure>\n\n\n\n
The file has now been committed.  Running the git status command shows updated\ninformation.  Also, the git ls-files<\/em>\nnow show the file added to the repo.  <\/p>\n\n\n\n
\n
Did a text editor open when running a commit?  That means you left off the -m \u201ccomment\u201d<\/em>.  It\u2019s 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.  <\/p>\n<\/blockquote>\n\n\n\n
Change tracking<\/h2>\n\n\n\n
To illustrate the change tracking ability of Git, I first\nneed to change the file.  I added some\ntest to my test file and saved it.  Next,\nI run the git add and git command again as I did before.<\/p>\n\n\n\n
\"\"<\/a>
 Second Commit <\/figcaption><\/figure>\n\n\n\n
The commit history is displayed with the git log<\/em>\ncommand as shown below.  Now you can see\nhow all the work so far has paid off.  The\noutput shows who made the changes, at what time and gives the comment\ninformation.  <\/p>\n\n\n\n
\"\"<\/a>
 Git Log Command <\/figcaption><\/figure>\n\n\n\n
This is all good, but what if you want to look at one of\nthose previous versions?  That is easy to\ndo with the git show<\/em> command.  The\ngit show<\/em> command requires the hash value (shown after commit<\/em> in\nthe image above) and the path to the file. \nBelow shows the output from both of my commits along with the content of\nthe file.<\/p>\n\n\n\n
git show <Commit Hash>:file\/path<\/pre>\n\n\n\n
\"\"<\/a>
 Git Show Command <\/figcaption><\/figure>\n\n\n\n
Is it worth it?<\/h2>\n\n\n\n
When I first started using Git it seemed like a lot of extra\nsteps.  It may seem redundant to have to\ndo a git add <\/em>and a git commit<\/em> to commit the file, but it makes\nsense if the directory has a lot of files. \nThe git add<\/em> command provides the ability to selectively add files.\n<\/p>\n\n\n\n
Keep in mind, the whole process is much easier with a code editor\nthat has Git integration.  Also, pushing\nchanges to a central repository keeps a copy in a secure offsite location.  That\u2019s safer than a USB thumb drive!<\/p>\n\n\n\n
To return to my original motive, Git provides:<\/p>\n\n\n\n