Git basics for IT pros: Using it with your PowerShell scripts

In a previous article, we introduced the basic concepts of Git for IT professionals. In this article, we will get a little bit more advanced by showing IP pros how to use Git to track their PowerShell scripts.

We will be installing Git on Windows Server or workstation, and then we will create our first repo, configure our personal information (which is required before starting the process to track changes), and finally work with some simple scenarios where we can take advantage of Git to control and use different versions.

Installing Git on a Windows Server/workstation

Git is available on all platforms: Linux, MacOS, and Windows. In Microsoft world, we can download the GitHub Desktop software and that one comes with Git built-in, however, we will play simple and we will install just Git itself on our Windows Server to test and validate the concepts introduced in our previous article.

The first step is to visit the Git website and download it for Windows. (You can use this link here.) It is also nice to have a useful code editor to play with files and Git during the installation will ask for your current code editor. Microsoft offers Visual Studio Code for free, and if you don’t have any preference, that could be a really good start. You can download it from here.

  1. In the Information page, the GNU (General Public License), which gives you the freedom to modify and share the software, will be displayed, click on Next.
  2. In the Select Destination Location page, by default it will be installed under C:\Program Files\Git, click on Next to continue.
  3. In the Select Components page, we can define the integration of Git with the Operating System. Click next.
  4. In the Select Start Menu Folder page, Git is the name that will be created in the start menu. Click on next.
  5. In the Choosing the default editor used by Git page, here is where we can select which editor we are going to use with Git.
    Note: If you haven’t installed your preferred editor yet, install it using the link provided by the installation wizard. After the installation, click on Back and next to refresh the newly installed software and that will allow the installation to continue.
    Git basics
  6. In the Adjusting your PATH environment page, here is how the environment variables will be configured to support Git. If you don’t have any special requirements leave the default settings and click Next.
  7. In the Choosing HTTPS transport backend page, we can define how Git will use the TLS library to be used with HTTPS connections (my preference for Windows is to use Use the native Windows Secure Channel Library option). Click on Next.
  8. In the Configuring the line ending conversions page, we can define how Git will work with ending lines in text files being controlled, and it matters how it is going to be your integration among platforms. Leave the default settings if you don’t have any requirement in this area, and click Next.
  9. In the Configuring the terminal emulator to use with Git Bash page, my preference in Windows is to select Use Windows’ default console window and click Next.
  10. In the Configuring extra options page, we can enable some options such as file caching and MFA (multifactor authentication), which are the first two options. Leave the default settings, and click Next.
  11. In the Completing the Git Setup Click on Finish.

Initializing the repository and first changes

Git keeps track of all changes, and, most important, it also tracks who performed the changes, which is great when working with teams. Although we are flying solo in this article, our first step is to define our name and email before starting tracking our upcoming scripts.

These following commands will define such parameters, and in the third and fourth commands, we will check the information that we have just entered.

Git config --global “Name Lastname”
Git config --global “[email protected]”
Git config --global --list

Now that we have Git installed on our Windows Server and we configured the local Git with our information for tracking purposes, let’s create a folder and initialize the Git repository (better known as repo). Open PowerShell and perform the commands listed below, which will create a new root folder called PSScripts (PowerShell Scripts) and then we are going inside of that folder to initialize the repo using git utility.

Cd \
Mkdir PSScripts
Cd PSScripts
git init

The results will be a new folder .git being created under C:\PSScripts as depicted in the image below.

Git basics

Time to create our first script file and add some code into it. We will create a new PowerShell script called Get-SecTLS.ps1 and after adding our first line of code, we will perform three separate actions, as follows: first we will check the content of the script just for reference, and then we will be adding the new file to the staging area (first command), then we will check the status of the Git in the current folder, and last but not least, we will commit that snapshot created on the first command to the local repository. All cmdlets are listed below, and the entire action can be seen in the image depicted below.

Command Brief Explanation
Get-content Get-SecTLS.ps1 View the current content of the file
Git add Get-SecTLS.ps1 Add the file to be tracked by git and to the stage area using the current content
Git status Check the status, it will inform that we have a new file that wasn’t committed yet
Git commit -m “string” Commit all the staged changes and the label for this commit will be the string provide after the -m


After the commit is executed (image below), we will run another Git status and at this time it informs us that we are working on the default branch called master and there is nothing being changed from the files that we are monitoring, and nothing to commit.

One important point is that the hash of the commit is informed in the output. We can use that hash to go back and forth in our commits later on.

Time to perform new updates. Let’s commit the second wave of changes, and we will perform the same sequence that we performed in the initial commit. You may be wondering, do I have to add it again? The answer is Yes, the Git add is to add any given file to the staging area, and it is not a onetime thing for the file. But after the first Git add, the file will be tracked moving forward. We will cover the process to remove a file from the list in a different article.

After making some changes to our script, we will run Git status and it will inform us that a previous tracked file has been modified. If we want to get a snapshot of what we have, then we should use Git add <file>, and after that another Git status will give us information that the modified file that we have just added is ready to be committed, which we do in the last command.

Git basics

Working with commits

Until this point, we wrote our code and when we had a good stable script, we committed the changes and label such commits for future reference.

Time to take advantage of Git using a few key features of the solution. Let’s start by checking where is the head, which is a pointer that shows where is the current change is being located. We can list all the commits using the following command (Step 1).

Git log --oneline --graph --all

Now that we know all the current commits, we can check the content of our script using the command in Step 2.

Get-content .\Get-SecTLS.ps1

Let’s pretend that our new additions are not good and we need to check what we had added in the first commit, we need to use the command below (Step 3 and Step 4) using the checksum associated to the commit that we want to restore, and after that we will check the content of our script and at this time the content will reflect the changes that we have committed in the first commit.

Git checkout <checksum>
Get-content .\Get-SecTLS.ps1

If we want to go back to the latest development, we can use master which is the branch name and that helps to move the HEAD back to the latest development (Steps 5 and 6).

Git checkout master
Get-content .\Get-SecTLS.ps1

Using Git we were able to check the stable commits of our script to the source control and be able to move back and forth to validate the script code without working with two different files. We were able to work with views in the same location.

We are going in more details and scenarios in our upcoming article, however, for now, we have enough tools in our toolbox to deploy and use Git to support our scripts.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top