Automation by way of scripts can be a powerful tool for change. Over the years, I’ve collected several hundred “one-off” scripts for various tasks using PowerShell and, more specifically, the cmdlets found in PowerCLI. Typically, these were plopped into Dropbox for a few reasons: easy to sync among my devices, a quick way to backup any changes, and the small size made them trivial on my overall capacity usage. However, it can be a challenge to share code written in Dropbox because it really wasn’t intended for that purpose.

What if there were an easier way to sync, backup, and share code? As it turns out, there is a wonderful way to do just this – it’s called GitHub. I realize that there’s nothing new in this statement as GitHub has been around for quite some time, but I never really thought about using it for my PowerShell code until recently. Since all of my code is just a compilation of small scripts, I figured it was not a fit for GitHub – after all, I’m not writing anything serious that compiles within these little scripts.

I have seen the light, however, and have begun going through some of my old scripts to find ones worth posting into my repositories. Maybe you’ll do the same?

I don't have much commit history yet, but it's a start — I don’t have much commit history yet, but it’s a start

Additionally, it’s nice to be able to publish your code for several other reasons:

It allows others in the community to use your efforts to solve their problems, or at least see how you were able to solve a similar problem and potentially find their own solution.
Other script authors can offer some improvements, updates, or bug fixes to your code in an environment that was created just for that purpose.
GitHub is a great way to show off your chops to potential employers and is a sort of living resume or technical portfolio.

[symple_box color=”blue” fade_in=”false” float=”center” text_align=”left” width=””]Warning: It is quite humbling to look over old scripts; expect to chuckle at yourself a little ;)[/symple_box]

The GitHub Lexicon

There’s a lot of new terms that I’ve learned while working with GitHub that might seem a little confusing or daunting at first. Most of the terms are foreign to anyone who works heavily with infrastructure for a living, so I’ll cover the important ones here:

Repository – This is a logical container for your code. It can contain files and folders of any type, with no single file being allowed to exceed 100 MB. By default, they are public – but you can pay a monthly fee to make them private. Private repositories, however, kinda of go against the grain of opening up your ideas and code to the greater community.
Commit – Any time you make a change to a file (or files) within a repository, you then need to commit those changes. It’s a lot like creating a virtual machine snapshot – you’re defining a point in time where you want to save the delta changes from the previous commit and the current code.
Fork – If you want to work on someone else’s code, you can fork it into your own repository. You are essentially making a copy of their code that you can then work on.
Pull – After you’ve forked someone’s code, you can make changes to it – such as bug fixes or feature improvements – and then send a pull request. You’re asking the owner of the code to pull your changes into their code.
Sync – Any time your local repository, located on your computer, differs from the GitHub repository, you’ll need to sync it. A sync is done from one repository to another, and in the framework of GitHub, is either between your local repository (on your computer) and GitHub or between two repositories on GitHub (common if you forked someone’s code).

As a primarily Windows dude, I rely on the GitHub for Windows client – you’re not forced to use Linux to also use GitHub (although it’s good idea to learn enough to be competent). The Windows client is rather nicely built with a friendly GUI, and only requires diving into the CLI for times when you need to stash your changes or resolve a conflict.

For more details on that, I ‘d suggest watching Brendan Enrick’s GitHub for Windows Developers course on Pluralsight. I recently watched the entire thing and found the content to be very helpful. You can also visit the GitHub Bootcamp section for more guides.